diff --git a/blog/2021-12-31-medical-diagnosis/index.html b/blog/2021-12-31-medical-diagnosis/index.html
index 463a23061..84c28916b 100644
--- a/blog/2021-12-31-medical-diagnosis/index.html
+++ b/blog/2021-12-31-medical-diagnosis/index.html
@@ -3746,7 +3746,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don’t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the “Manager” cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation’s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV’s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern’s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/blog/2022-03-23-acm-mustonlyhave/index.html b/blog/2022-03-23-acm-mustonlyhave/index.html
index 09b8f01c2..947939b9b 100644
--- a/blog/2022-03-23-acm-mustonlyhave/index.html
+++ b/blog/2022-03-23-acm-mustonlyhave/index.html
@@ -3816,7 +3816,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don’t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the “Manager” cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation’s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV’s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern’s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/blog/2022-03-30-multicloud-gitops/index.html b/blog/2022-03-30-multicloud-gitops/index.html
index b07f565f1..d99574c77 100644
--- a/blog/2022-03-30-multicloud-gitops/index.html
+++ b/blog/2022-03-30-multicloud-gitops/index.html
@@ -3740,7 +3740,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don’t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the “Manager” cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation’s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV’s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern’s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/blog/2022-06-30-ansible-edge-gitops/index.html b/blog/2022-06-30-ansible-edge-gitops/index.html
index 97cde23bf..eba90fe13 100644
--- a/blog/2022-06-30-ansible-edge-gitops/index.html
+++ b/blog/2022-06-30-ansible-edge-gitops/index.html
@@ -3739,7 +3739,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don’t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the “Manager” cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation’s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV’s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern’s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/blog/2022-07-15-push-vs-pull/index.html b/blog/2022-07-15-push-vs-pull/index.html
index 93bf9b750..bd10aa4e5 100644
--- a/blog/2022-07-15-push-vs-pull/index.html
+++ b/blog/2022-07-15-push-vs-pull/index.html
@@ -3740,7 +3740,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don’t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the “Manager” cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation’s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV’s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern’s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/blog/2022-08-24-clustergroups/index.html b/blog/2022-08-24-clustergroups/index.html
index 540a1cfb4..f054d6b0a 100644
--- a/blog/2022-08-24-clustergroups/index.html
+++ b/blog/2022-08-24-clustergroups/index.html
@@ -3739,7 +3739,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don’t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the “Manager” cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation’s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV’s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern’s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/blog/2022-09-02-route/index.html b/blog/2022-09-02-route/index.html
index e11cc12d1..4ace2f42e 100644
--- a/blog/2022-09-02-route/index.html
+++ b/blog/2022-09-02-route/index.html
@@ -3816,7 +3816,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don’t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the “Manager” cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation’s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV’s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern’s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/blog/2022-10-12-acm-provisioning/index.html b/blog/2022-10-12-acm-provisioning/index.html
index e2cdcb145..e49b1aa04 100644
--- a/blog/2022-10-12-acm-provisioning/index.html
+++ b/blog/2022-10-12-acm-provisioning/index.html
@@ -3826,7 +3826,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don’t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the “Manager” cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation’s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV’s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern’s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/blog/2022-11-20-argo-rollouts/index.html b/blog/2022-11-20-argo-rollouts/index.html
index 0bb61fe48..b6ad29045 100644
--- a/blog/2022-11-20-argo-rollouts/index.html
+++ b/blog/2022-11-20-argo-rollouts/index.html
@@ -3942,7 +3942,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don’t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the “Manager” cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation’s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV’s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern’s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/blog/2022-12-01-multicluster-devsecops/index.html b/blog/2022-12-01-multicluster-devsecops/index.html
index 1bcb8b042..91132979a 100644
--- a/blog/2022-12-01-multicluster-devsecops/index.html
+++ b/blog/2022-12-01-multicluster-devsecops/index.html
@@ -3745,7 +3745,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don’t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the “Manager” cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation’s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV’s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern’s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/blog/2023-11-17-argo-configmanagement-plugins/index.html b/blog/2023-11-17-argo-configmanagement-plugins/index.html
index 88a64c4b2..bb1a2e9a9 100644
--- a/blog/2023-11-17-argo-configmanagement-plugins/index.html
+++ b/blog/2023-11-17-argo-configmanagement-plugins/index.html
@@ -3824,7 +3824,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don’t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the “Manager” cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation’s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV’s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern’s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/blog/2023-12-01-new-pattern-tiers/index.html b/blog/2023-12-01-new-pattern-tiers/index.html
index 1f06347b3..68483b5db 100644
--- a/blog/2023-12-01-new-pattern-tiers/index.html
+++ b/blog/2023-12-01-new-pattern-tiers/index.html
@@ -3739,7 +3739,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don’t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the “Manager” cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation’s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV’s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern’s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/blog/2023-12-05-nutanix-testing/index.html b/blog/2023-12-05-nutanix-testing/index.html
index 915258b17..7d68c15db 100644
--- a/blog/2023-12-05-nutanix-testing/index.html
+++ b/blog/2023-12-05-nutanix-testing/index.html
@@ -3740,7 +3740,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don’t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the “Manager” cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation’s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV’s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern’s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/blog/2023-12-15-understanding-namespaces/index.html b/blog/2023-12-15-understanding-namespaces/index.html
index 5bd5b7388..425cd57ba 100644
--- a/blog/2023-12-15-understanding-namespaces/index.html
+++ b/blog/2023-12-15-understanding-namespaces/index.html
@@ -3825,7 +3825,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don’t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the “Manager” cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation’s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV’s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern’s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/blog/2023-12-20-private-repos/index.html b/blog/2023-12-20-private-repos/index.html
index 959cda0b4..5dafa3eaf 100644
--- a/blog/2023-12-20-private-repos/index.html
+++ b/blog/2023-12-20-private-repos/index.html
@@ -3782,7 +3782,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don’t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the “Manager” cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation’s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV’s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern’s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/blog/2024-01-16-deploying-mcg-with-cisco-flashstack-portworx/index.html b/blog/2024-01-16-deploying-mcg-with-cisco-flashstack-portworx/index.html
index d75049bc9..5a148f152 100644
--- a/blog/2024-01-16-deploying-mcg-with-cisco-flashstack-portworx/index.html
+++ b/blog/2024-01-16-deploying-mcg-with-cisco-flashstack-portworx/index.html
@@ -3738,7 +3738,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don’t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the “Manager” cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation’s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV’s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern’s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/blog/2024-01-26-more-secrets-options/index.html b/blog/2024-01-26-more-secrets-options/index.html
index 2613b99a2..2803aa20c 100644
--- a/blog/2024-01-26-more-secrets-options/index.html
+++ b/blog/2024-01-26-more-secrets-options/index.html
@@ -3881,7 +3881,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don’t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the “Manager” cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation’s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV’s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern’s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/blog/2024-02-07-hcp-htpasswd-config/index.html b/blog/2024-02-07-hcp-htpasswd-config/index.html
index 7ee705238..c07893fee 100644
--- a/blog/2024-02-07-hcp-htpasswd-config/index.html
+++ b/blog/2024-02-07-hcp-htpasswd-config/index.html
@@ -3768,7 +3768,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don’t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the “Manager” cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation’s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV’s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern’s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/blog/2024-03-05-intel-accelerated-patterns/index.html b/blog/2024-03-05-intel-accelerated-patterns/index.html
index 8e21a9aed..883db5cdd 100644
--- a/blog/2024-03-05-intel-accelerated-patterns/index.html
+++ b/blog/2024-03-05-intel-accelerated-patterns/index.html
@@ -3739,7 +3739,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don’t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the “Manager” cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation’s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV’s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern’s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/blog/2024-07-12-in-cluster-git/index.html b/blog/2024-07-12-in-cluster-git/index.html
index 49f376fb5..77509c6bc 100644
--- a/blog/2024-07-12-in-cluster-git/index.html
+++ b/blog/2024-07-12-in-cluster-git/index.html
@@ -3778,7 +3778,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don’t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the “Manager” cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation’s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV’s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern’s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/blog/2024-07-19-write-token-kubeconfig/index.html b/blog/2024-07-19-write-token-kubeconfig/index.html
index 394795a4f..4ee7af31a 100644
--- a/blog/2024-07-19-write-token-kubeconfig/index.html
+++ b/blog/2024-07-19-write-token-kubeconfig/index.html
@@ -3751,7 +3751,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don’t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the “Manager” cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation’s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV’s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern’s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/blog/2024-08-30-push-secrets/index.html b/blog/2024-08-30-push-secrets/index.html
index ca32a0d3f..a8ca19467 100644
--- a/blog/2024-08-30-push-secrets/index.html
+++ b/blog/2024-08-30-push-secrets/index.html
@@ -3784,7 +3784,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don’t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the “Manager” cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation’s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV’s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern’s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/blog/2024-09-13-using-hypershift/index.html b/blog/2024-09-13-using-hypershift/index.html
index b4f600a16..7b9b5c775 100644
--- a/blog/2024-09-13-using-hypershift/index.html
+++ b/blog/2024-09-13-using-hypershift/index.html
@@ -3802,7 +3802,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don’t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the “Manager” cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation’s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV’s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern’s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/blog/2024-09-26-slimming-of-common/index.html b/blog/2024-09-26-slimming-of-common/index.html
index 3d21d6b78..5dba2aff5 100644
--- a/blog/2024-09-26-slimming-of-common/index.html
+++ b/blog/2024-09-26-slimming-of-common/index.html
@@ -3800,7 +3800,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don’t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the “Manager” cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation’s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV’s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern’s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/blog/2024-10-12-disconnected/index.html b/blog/2024-10-12-disconnected/index.html
index 9ff6fc77b..8e73ef4e2 100644
--- a/blog/2024-10-12-disconnected/index.html
+++ b/blog/2024-10-12-disconnected/index.html
@@ -3838,7 +3838,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don’t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the “Manager” cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation’s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV’s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern’s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/blog/2024-11-07-clustergroup-sequencing/index.html b/blog/2024-11-07-clustergroup-sequencing/index.html
index f3f4cc8f2..b190ccfe7 100644
--- a/blog/2024-11-07-clustergroup-sequencing/index.html
+++ b/blog/2024-11-07-clustergroup-sequencing/index.html
@@ -3943,7 +3943,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don’t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the “Manager” cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation’s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV’s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern’s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/blog/index.html b/blog/index.html
index 06810ddfe..68e01ca34 100644
--- a/blog/index.html
+++ b/blog/index.html
@@ -3742,7 +3742,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don’t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the “Manager” cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation’s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV’s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern’s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/blog/page/2/index.html b/blog/page/2/index.html
index 60b6cf330..df6e06bef 100644
--- a/blog/page/2/index.html
+++ b/blog/page/2/index.html
@@ -3741,7 +3741,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don’t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the “Manager” cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation’s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV’s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern’s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/blog/page/3/index.html b/blog/page/3/index.html
index 5a1b263ba..33484d8f4 100644
--- a/blog/page/3/index.html
+++ b/blog/page/3/index.html
@@ -3752,7 +3752,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don’t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the “Manager” cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation’s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV’s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern’s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/blog/page/4/index.html b/blog/page/4/index.html
index 49bae0cb8..b1c834df8 100644
--- a/blog/page/4/index.html
+++ b/blog/page/4/index.html
@@ -3746,7 +3746,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don’t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the “Manager” cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation’s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV’s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern’s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/blog/page/5/index.html b/blog/page/5/index.html
index 228ae7901..b058974c1 100644
--- a/blog/page/5/index.html
+++ b/blog/page/5/index.html
@@ -3738,7 +3738,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don’t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the “Manager” cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation’s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV’s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern’s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/blog_tags/acm/index.html b/blog_tags/acm/index.html
index 4b53fa098..4e9ce2aa2 100644
--- a/blog_tags/acm/index.html
+++ b/blog_tags/acm/index.html
@@ -3740,7 +3740,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don’t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the “Manager” cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation’s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV’s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern’s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/blog_tags/acs/index.html b/blog_tags/acs/index.html
index 55779c242..5695be52f 100644
--- a/blog_tags/acs/index.html
+++ b/blog_tags/acs/index.html
@@ -3744,7 +3744,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don’t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the “Manager” cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation’s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV’s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern’s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/blog_tags/announce/index.html b/blog_tags/announce/index.html
index e3b55b5ec..feafd0e32 100644
--- a/blog_tags/announce/index.html
+++ b/blog_tags/announce/index.html
@@ -3742,7 +3742,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don’t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the “Manager” cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation’s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV’s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern’s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/blog_tags/ansible-edge-gitops/index.html b/blog_tags/ansible-edge-gitops/index.html
index 5a618e8c0..1dfa6b221 100644
--- a/blog_tags/ansible-edge-gitops/index.html
+++ b/blog_tags/ansible-edge-gitops/index.html
@@ -3740,7 +3740,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don’t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the “Manager” cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation’s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV’s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern’s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/blog_tags/devops/index.html b/blog_tags/devops/index.html
index 9dda438ce..9cca09161 100644
--- a/blog_tags/devops/index.html
+++ b/blog_tags/devops/index.html
@@ -3749,7 +3749,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don’t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the “Manager” cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation’s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV’s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern’s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/blog_tags/devsecops/index.html b/blog_tags/devsecops/index.html
index f4dcbecaf..4503c3bb4 100644
--- a/blog_tags/devsecops/index.html
+++ b/blog_tags/devsecops/index.html
@@ -3749,7 +3749,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don’t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the “Manager” cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation’s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV’s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern’s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/blog_tags/git/index.html b/blog_tags/git/index.html
index 3eb7c612f..4adb5884f 100644
--- a/blog_tags/git/index.html
+++ b/blog_tags/git/index.html
@@ -3738,7 +3738,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don’t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the “Manager” cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation’s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV’s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern’s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/blog_tags/gitops/index.html b/blog_tags/gitops/index.html
index 4b4c81052..1e8136817 100644
--- a/blog_tags/gitops/index.html
+++ b/blog_tags/gitops/index.html
@@ -3748,7 +3748,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don’t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the “Manager” cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation’s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV’s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern’s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/blog_tags/how-to/index.html b/blog_tags/how-to/index.html
index f338042b7..a8900ae8e 100644
--- a/blog_tags/how-to/index.html
+++ b/blog_tags/how-to/index.html
@@ -3744,7 +3744,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don’t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the “Manager” cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation’s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV’s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern’s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/blog_tags/index.html b/blog_tags/index.html
index d48a45c5e..22d2d97fc 100644
--- a/blog_tags/index.html
+++ b/blog_tags/index.html
@@ -3737,7 +3737,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don’t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the “Manager” cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation’s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV’s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern’s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/blog_tags/medical-diagnosis/index.html b/blog_tags/medical-diagnosis/index.html
index f59b0ba12..f8d6f81bc 100644
--- a/blog_tags/medical-diagnosis/index.html
+++ b/blog_tags/medical-diagnosis/index.html
@@ -3739,7 +3739,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don’t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the “Manager” cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation’s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV’s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern’s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/blog_tags/multi-cloud-gitops/index.html b/blog_tags/multi-cloud-gitops/index.html
index d16bb5307..700d7cf47 100644
--- a/blog_tags/multi-cloud-gitops/index.html
+++ b/blog_tags/multi-cloud-gitops/index.html
@@ -3739,7 +3739,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don’t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the “Manager” cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation’s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV’s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern’s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/blog_tags/nutanix/index.html b/blog_tags/nutanix/index.html
index 7225c709c..fae59bcd8 100644
--- a/blog_tags/nutanix/index.html
+++ b/blog_tags/nutanix/index.html
@@ -3739,7 +3739,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don’t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the “Manager” cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation’s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV’s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern’s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/blog_tags/openshift-platform-plus/index.html b/blog_tags/openshift-platform-plus/index.html
index 93d6f7afc..10a2e0bbd 100644
--- a/blog_tags/openshift-platform-plus/index.html
+++ b/blog_tags/openshift-platform-plus/index.html
@@ -3749,7 +3749,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don’t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the “Manager” cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation’s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV’s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern’s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/blog_tags/openshift/index.html b/blog_tags/openshift/index.html
index ba3ae5746..0c7f9d1a4 100644
--- a/blog_tags/openshift/index.html
+++ b/blog_tags/openshift/index.html
@@ -3739,7 +3739,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don’t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the “Manager” cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation’s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV’s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern’s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/blog_tags/page/2/index.html b/blog_tags/page/2/index.html
index 206df7872..ea0a54b66 100644
--- a/blog_tags/page/2/index.html
+++ b/blog_tags/page/2/index.html
@@ -3737,7 +3737,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don’t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the “Manager” cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation’s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV’s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern’s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/blog_tags/page/3/index.html b/blog_tags/page/3/index.html
index d1e97cde4..c0387798b 100644
--- a/blog_tags/page/3/index.html
+++ b/blog_tags/page/3/index.html
@@ -3737,7 +3737,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don’t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the “Manager” cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation’s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV’s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern’s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/blog_tags/page/4/index.html b/blog_tags/page/4/index.html
index 00f04ae83..c8b949607 100644
--- a/blog_tags/page/4/index.html
+++ b/blog_tags/page/4/index.html
@@ -3737,7 +3737,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don’t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the “Manager” cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation’s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV’s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern’s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/blog_tags/page/5/index.html b/blog_tags/page/5/index.html
index 77366d7f7..86b1ff0a4 100644
--- a/blog_tags/page/5/index.html
+++ b/blog_tags/page/5/index.html
@@ -3737,7 +3737,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don’t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the “Manager” cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation’s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV’s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern’s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/blog_tags/patterns/index.html b/blog_tags/patterns/index.html
index cf57b1343..8b26e30f1 100644
--- a/blog_tags/patterns/index.html
+++ b/blog_tags/patterns/index.html
@@ -3743,7 +3743,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don’t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the “Manager” cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation’s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV’s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern’s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/blog_tags/patterns/page/2/index.html b/blog_tags/patterns/page/2/index.html
index 22600bcbe..dc8dd1948 100644
--- a/blog_tags/patterns/page/2/index.html
+++ b/blog_tags/patterns/page/2/index.html
@@ -3742,7 +3742,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don’t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the “Manager” cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation’s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV’s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern’s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/blog_tags/patterns/page/3/index.html b/blog_tags/patterns/page/3/index.html
index 22c42fa10..41209c5a9 100644
--- a/blog_tags/patterns/page/3/index.html
+++ b/blog_tags/patterns/page/3/index.html
@@ -3753,7 +3753,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don’t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the “Manager” cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation’s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV’s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern’s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/blog_tags/patterns/page/4/index.html b/blog_tags/patterns/page/4/index.html
index 78ac4918d..af798d953 100644
--- a/blog_tags/patterns/page/4/index.html
+++ b/blog_tags/patterns/page/4/index.html
@@ -3743,7 +3743,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don’t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the “Manager” cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation’s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV’s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern’s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/blog_tags/pipelines/index.html b/blog_tags/pipelines/index.html
index 516bc34bf..b4286dec3 100644
--- a/blog_tags/pipelines/index.html
+++ b/blog_tags/pipelines/index.html
@@ -3749,7 +3749,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don’t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the “Manager” cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation’s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV’s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern’s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/blog_tags/provisioning/index.html b/blog_tags/provisioning/index.html
index a8492f988..8a75d480b 100644
--- a/blog_tags/provisioning/index.html
+++ b/blog_tags/provisioning/index.html
@@ -3740,7 +3740,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don’t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the “Manager” cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation’s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV’s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern’s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/blog_tags/quay/index.html b/blog_tags/quay/index.html
index 1942f4d80..474d08b67 100644
--- a/blog_tags/quay/index.html
+++ b/blog_tags/quay/index.html
@@ -3744,7 +3744,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don’t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the “Manager” cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation’s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV’s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern’s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/blog_tags/route/index.html b/blog_tags/route/index.html
index cdc391e3e..de1045865 100644
--- a/blog_tags/route/index.html
+++ b/blog_tags/route/index.html
@@ -3739,7 +3739,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don’t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the “Manager” cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation’s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV’s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern’s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/blog_tags/secrets/index.html b/blog_tags/secrets/index.html
index dc6f56720..3c77d3f6a 100644
--- a/blog_tags/secrets/index.html
+++ b/blog_tags/secrets/index.html
@@ -3738,7 +3738,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don’t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the “Manager” cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation’s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV’s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern’s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/blog_tags/security/index.html b/blog_tags/security/index.html
index 53e9af2fa..36e230308 100644
--- a/blog_tags/security/index.html
+++ b/blog_tags/security/index.html
@@ -3744,7 +3744,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don’t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the “Manager” cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation’s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV’s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern’s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/blog_tags/sequencing/index.html b/blog_tags/sequencing/index.html
index 8a64d0cdf..d727ef64c 100644
--- a/blog_tags/sequencing/index.html
+++ b/blog_tags/sequencing/index.html
@@ -3740,7 +3740,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don’t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the “Manager” cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation’s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV’s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern’s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/blog_tags/subscriptions/index.html b/blog_tags/subscriptions/index.html
index fc939d4e8..3480a9582 100644
--- a/blog_tags/subscriptions/index.html
+++ b/blog_tags/subscriptions/index.html
@@ -3740,7 +3740,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don’t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the “Manager” cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation’s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV’s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern’s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/blog_tags/validated-pattern/index.html b/blog_tags/validated-pattern/index.html
index d553b4a91..ec2cd4ac9 100644
--- a/blog_tags/validated-pattern/index.html
+++ b/blog_tags/validated-pattern/index.html
@@ -3743,7 +3743,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don’t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the “Manager” cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation’s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV’s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern’s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/blog_tags/xray/index.html b/blog_tags/xray/index.html
index 0c4b868e4..707a50132 100644
--- a/blog_tags/xray/index.html
+++ b/blog_tags/xray/index.html
@@ -3741,7 +3741,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don’t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the “Manager” cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation’s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV’s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern’s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/ci/index.html b/ci/index.html
index db307cf41..24b4d7064 100644
--- a/ci/index.html
+++ b/ci/index.html
@@ -3742,7 +3742,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don’t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the “Manager” cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation’s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV’s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern’s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/ci/internal/index.html b/ci/internal/index.html
index fb0a6f2ac..593154491 100644
--- a/ci/internal/index.html
+++ b/ci/internal/index.html
@@ -3741,7 +3741,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don’t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the “Manager” cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation’s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV’s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern’s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/contribute/background-on-pattern-development/index.html b/contribute/background-on-pattern-development/index.html
index e80eaa3bf..3265c8ed7 100644
--- a/contribute/background-on-pattern-development/index.html
+++ b/contribute/background-on-pattern-development/index.html
@@ -3737,7 +3737,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don’t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the “Manager” cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation’s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV’s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern’s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/contribute/contribute-to-docs/index.html b/contribute/contribute-to-docs/index.html
index b884731f9..84059ac41 100644
--- a/contribute/contribute-to-docs/index.html
+++ b/contribute/contribute-to-docs/index.html
@@ -3795,7 +3795,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don’t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the “Manager” cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation’s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV’s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern’s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/contribute/creating-a-pattern/index.html b/contribute/creating-a-pattern/index.html
index f460495bf..d48174fc6 100644
--- a/contribute/creating-a-pattern/index.html
+++ b/contribute/creating-a-pattern/index.html
@@ -3824,7 +3824,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don’t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the “Manager” cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation’s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV’s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern’s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/contribute/extending-a-pattern/index.html b/contribute/extending-a-pattern/index.html
index 1df968b72..249c9411f 100644
--- a/contribute/extending-a-pattern/index.html
+++ b/contribute/extending-a-pattern/index.html
@@ -3841,7 +3841,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don’t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the “Manager” cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation’s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV’s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern’s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/contribute/index.html b/contribute/index.html
index 8b48b3cc1..f4f60c675 100644
--- a/contribute/index.html
+++ b/contribute/index.html
@@ -3736,7 +3736,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don’t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the “Manager” cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation’s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV’s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern’s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/contribute/support-policies/index.html b/contribute/support-policies/index.html
index b2b5cf419..1986400c0 100644
--- a/contribute/support-policies/index.html
+++ b/contribute/support-policies/index.html
@@ -3737,7 +3737,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: "." chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don’t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the “Manager” cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation’s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV’s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern’s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/images/logos/regional-dr.png b/images/logos/regional-dr.png
new file mode 100644
index 000000000..b997ce7ba
Binary files /dev/null and b/images/logos/regional-dr.png differ
diff --git a/images/regional-resiliency-pattern/architecture-diagram-vp-regional-dr-v6.png b/images/regional-resiliency-pattern/architecture-diagram-vp-regional-dr-v6.png
new file mode 100644
index 000000000..94e25501b
Binary files /dev/null and b/images/regional-resiliency-pattern/architecture-diagram-vp-regional-dr-v6.png differ
diff --git a/images/regional-resiliency-pattern/logical-architecture-diagram-vp-regional-dr-v6.png b/images/regional-resiliency-pattern/logical-architecture-diagram-vp-regional-dr-v6.png
new file mode 100644
index 000000000..c48010f98
Binary files /dev/null and b/images/regional-resiliency-pattern/logical-architecture-diagram-vp-regional-dr-v6.png differ
diff --git a/index.html b/index.html
index 0214672a2..2d3232f8b 100644
--- a/index.html
+++ b/index.html
@@ -2,8 +2,8 @@
 </span><input id=search-input name=query class=pf-c-search-input__text-input type=text placeholder=Search aria-label=Search></span></div><button form=search class="pf-c-button pf-m-control" type=submit aria-label=Search value=search>
 <i class="fas fa-arrow-right" aria-hidden=true></i></button></div></div></form></div></header><main class=pf-c-page__main><section class="pf-c-page__main-section pf-m-light pf-m-dark-100 pf-u-background-color-primary-color-200" style=background-image:url(/images/background.svg);background-position:50%;background-size:cover><div class=pf-l-grid><div class="pf-l-grid__item pf-m-12-col-on-sm pf-m-8-col-on-md pf-m-offset-2-col-on-md pf-m-6-col-on-lg pf-m-offset-3-col-on-lg pf-u-py-2xl pf-u-text-align-center"><div class=pf-c-content><p><img src=/images/logo.png alt=Logo></p><h1 id=reference-architectures-with-added-value>Reference architectures with added value</h1><p>Validated Patterns are an evolution of how you deploy applications in a hybrid cloud. With a pattern, you can automatically deploy a full application stack through a GitOps-based framework. With this framework, you can create business-centric solutions while maintaining a level of Continuous Integration (CI) over your application.</p><a href=/learn class="pf-c-button pf-m-primary" style=--pf-c-button--m-primary--BackgroundColor:var(--pf-global--palette--blue-300);--pf-c-button--m-primary--Color:var(--pf-global--palette--white);--pf-c-button--BorderRadius:20px;--pf-c-button--after--BorderRadius:20px>Learn more</a></div></div></div></section><section class="pf-c-page__main-section pf-m-dark-100 pf-u-background-color-dark-300"><div class=pf-l-grid><div class="pf-l-grid__item pf-m-12-col-on-sm pf-m-8-col-on-md pf-m-offset-2-col-on-md pf-m-8-col-on-lg pf-m-offset-2-col-on-lg pf-u-py-2xl pf-u-text-align-center"><div class=pf-c-content><h1>Watch how validated patterns enhance your cloud-native applications</h1><iframe style=height:450px width=800 height=450 src=https://www.youtube.com/embed/dGsoUNjHYOw title="YouTube video player" frameborder=0 allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen></iframe></div></div></section><section class=pf-c-page__main-section><div class=pf-l-grid><div class="pf-l-grid__item pf-m-12-col-on-sm pf-m-8-col-on-md pf-m-offset-2-col-on-md pf-m-8-col-on-lg pf-m-offset-2-col-on-lg pf-u-py-2xl"><div class=pf-c-content><h1 class="pf-c-title pf-m-4xl">Latest Patterns</h1><div class="pf-l-gallery pf-m-gutter" style=--pf-l-gallery--GridTemplateColumns--min:300px><div class=pf-l-gallery__item style=display:grid><div class=pf-c-card style=text-align:left;--pf-c-card__title--FontSize:1rem;--pf-c-card__body--FontSize:0.95rem><div class=pf-c-card__title><a href=/patterns/ansible-edge-gitops-kasten/>Ansible Edge GitOps with Veeam Kasten</a></div><div class=pf-c-card__body>This pattern uses OpenShift Virtualization to simulate an edge environment for VMs, protected by Veeam Kasten.</div><div class=pf-c-card__footer><span class="pf-c-label pf-m-orange"><span class=pf-c-label__content><img src=/images/pattern-tier-sandbox.png alt=Sandbox width=16 height=16 class=custom-pattern-icon>
 Sandbox</span></span></div></div></div><div class=pf-l-gallery__item style=display:grid><div class=pf-c-card style=text-align:left;--pf-c-card__title--FontSize:1rem;--pf-c-card__body--FontSize:0.95rem><div class=pf-c-card__title><a href=/patterns/coco-pattern/>Confidential Containers pattern</a></div><div class=pf-c-card__body>This pattern helps you get started with deploying confidential containers in OpenShift Container Platform.</div><div class=pf-c-card__footer><span class="pf-c-label pf-m-orange"><span class=pf-c-label__content><img src=/images/pattern-tier-sandbox.png alt=Sandbox width=16 height=16 class=custom-pattern-icon>
-Sandbox</span></span></div></div></div><div class=pf-l-gallery__item style=display:grid><div class=pf-c-card style=text-align:left;--pf-c-card__title--FontSize:1rem;--pf-c-card__body--FontSize:0.95rem><div class=pf-c-card__title><a href=/patterns/rag-llm-gitops/>AI Generation with LLM and RAG</a></div><div class=pf-c-card__body>The goal of this demo is to demonstrate a Chatbot LLM application augmented with data from Red Hat product documentation running on Red Hat OpenShift. It deploys an LLM application that connects to multiple LLM providers such as OpenAI, Hugging Face, and NVIDIA NIM. The application generates a project proposal for a Red Hat product.</div><div class=pf-c-card__footer><span class="pf-c-label pf-m-blue"><span class=pf-c-label__content><img src=/images/pattern-tier-tested.png alt=Tested width=16 height=16 class=custom-pattern-icon>
-Tested</span></span></div></div></div></div></div></div></div></section><section class="pf-c-page__main-section pf-u-background-color-primary-color-100"><div class=pf-c-page__main-body><div class="pf-l-grid pf-m-light"><div class="pf-l-grid__item pf-m-12-col-on-sm pf-m-8-col-on-md pf-m-offset-2-col-on-md pf-m-8-col-on-lg pf-m-offset-2-col-on-lg pf-u-py-2xl"><div class=pf-c-content><h1 class="pf-c-title pf-m-4xl">Latest Blog Post</h1><div class=pf-c-card style=margin-bottom:10px><div class=pf-c-card__title><a href=/blog/2024-11-07-clustergroup-sequencing/><h1>Additional Sequencing Capabilities in clusterGroup</h1></a></div><div class=pf-c-card__body><p>by Martin Jackson</p><p>November 7, 2024</p><p>How to sequence subscriptions in the Validated Patterns framework</p><span class="pf-c-label pf-grey"><span class=pf-c-label__content>patterns</span>
+Sandbox</span></span></div></div></div><div class=pf-l-gallery__item style=display:grid><div class=pf-c-card style=text-align:left;--pf-c-card__title--FontSize:1rem;--pf-c-card__body--FontSize:0.95rem><div class=pf-c-card__title><a href=/patterns/regional-dr/>Regional Disaster Recovery</a></div><div class=pf-c-card__body>This variant of the Validated Patterns framework deploys a Regional Disaster Recovery Setup across multiple different regions</div><div class=pf-c-card__footer><span class="pf-c-label pf-m-orange"><span class=pf-c-label__content><img src=/images/pattern-tier-sandbox.png alt=Sandbox width=16 height=16 class=custom-pattern-icon>
+Sandbox</span></span></div></div></div></div></div></div></div></section><section class="pf-c-page__main-section pf-u-background-color-primary-color-100"><div class=pf-c-page__main-body><div class="pf-l-grid pf-m-light"><div class="pf-l-grid__item pf-m-12-col-on-sm pf-m-8-col-on-md pf-m-offset-2-col-on-md pf-m-8-col-on-lg pf-m-offset-2-col-on-lg pf-u-py-2xl"><div class=pf-c-content><h1 class="pf-c-title pf-m-4xl">Latest Blog Post</h1><div class=pf-c-card style=margin-bottom:10px><div class=pf-c-card__title><a href=/blog/2024-11-07-clustergroup-sequencing/><h1>Additional Sequencing Capabilities in clusterGroup</h1></a></div><div class=pf-c-card__body><p>by Martin Jackson</p><p>November 7, 2024</p><p>How to sequence subscriptions in the Validated Patterns framework</p><span class="pf-c-label pf-grey"><span class=pf-c-label__content>patterns</span>
 </span><span class="pf-c-label pf-grey"><span class=pf-c-label__content>how-to</span>
 </span><span class="pf-c-label pf-grey"><span class=pf-c-label__content>sequencing</span>
 </span><span class="pf-c-label pf-grey"><span class=pf-c-label__content>subscriptions</span></span></div></div></div></div></div></div></section><section id=prefooter class="pf-c-page__main-section footer-dark"><div class="pf-l-grid prefooter-menu-grid"><div class="pf-l-grid__item pf-m-12-col-on-sm pf-m-6-col-on-md pf-m-offset-1-col-on-md pf-u-mb-lg pf-u-mb-0-on-sm"><div class="pf-l-grid pf-u-py-xl"><div class="pf-l-grid__item pf-m-6-col-on-sm pf-m-4-col-on-md pf-u-ml-md pf-u-ml-0-on-md pf-u-mb-xl pf-u-mb-0-on-md"><p class="pf-c-title footer-menu-title">QUICKLINKS</p><nav aria-label="Quick Links"><ul class="pf-c-list pf-m-plain"><li><i class="prefooter-icon fa-brands fa-github"></i>
@@ -3742,7 +3742,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/learn/about-pattern-tiers-types/index.html b/learn/about-pattern-tiers-types/index.html
index 714cb7768..8424ec90a 100644
--- a/learn/about-pattern-tiers-types/index.html
+++ b/learn/about-pattern-tiers-types/index.html
@@ -3744,7 +3744,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/learn/about-validated-patterns/index.html b/learn/about-validated-patterns/index.html
index 74aa69172..f45e9b1d4 100644
--- a/learn/about-validated-patterns/index.html
+++ b/learn/about-validated-patterns/index.html
@@ -3744,7 +3744,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/learn/clustergroup-in-values-files/index.html b/learn/clustergroup-in-values-files/index.html
index 3b03ea21f..034666a8a 100644
--- a/learn/clustergroup-in-values-files/index.html
+++ b/learn/clustergroup-in-values-files/index.html
@@ -3876,7 +3876,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/learn/faq/index.html b/learn/faq/index.html
index 274191faf..1e21b2928 100644
--- a/learn/faq/index.html
+++ b/learn/faq/index.html
@@ -3744,7 +3744,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/learn/implementation/index.html b/learn/implementation/index.html
index 382ecbe87..3184bee62 100644
--- a/learn/implementation/index.html
+++ b/learn/implementation/index.html
@@ -3744,7 +3744,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/learn/importing-a-cluster/index.html b/learn/importing-a-cluster/index.html
index c0c13135e..a6a1b8e6c 100644
--- a/learn/importing-a-cluster/index.html
+++ b/learn/importing-a-cluster/index.html
@@ -3744,7 +3744,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/learn/index.html b/learn/index.html
index 8aa4cc1dc..92a057ad8 100644
--- a/learn/index.html
+++ b/learn/index.html
@@ -3744,7 +3744,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/learn/infrastructure/index.html b/learn/infrastructure/index.html
index a812a7344..efa31c0f5 100644
--- a/learn/infrastructure/index.html
+++ b/learn/infrastructure/index.html
@@ -3744,7 +3744,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/learn/keyconcepts/index.html b/learn/keyconcepts/index.html
index 3edb5c41e..85c644afa 100644
--- a/learn/keyconcepts/index.html
+++ b/learn/keyconcepts/index.html
@@ -3750,7 +3750,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/learn/maintained/index.html b/learn/maintained/index.html
index d3aaab7df..4fdd3f511 100644
--- a/learn/maintained/index.html
+++ b/learn/maintained/index.html
@@ -3745,7 +3745,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/learn/ocp-cluster-general-sizing/index.html b/learn/ocp-cluster-general-sizing/index.html
index 10c946161..82b5743fa 100644
--- a/learn/ocp-cluster-general-sizing/index.html
+++ b/learn/ocp-cluster-general-sizing/index.html
@@ -3746,7 +3746,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/learn/page/2/index.html b/learn/page/2/index.html
index 1830ff844..12e6e2ee4 100644
--- a/learn/page/2/index.html
+++ b/learn/page/2/index.html
@@ -3743,7 +3743,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/learn/page/3/index.html b/learn/page/3/index.html
index 6d6c1db4f..c4a903d4b 100644
--- a/learn/page/3/index.html
+++ b/learn/page/3/index.html
@@ -3743,7 +3743,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/learn/page/4/index.html b/learn/page/4/index.html
index bfd88653c..50886ac13 100644
--- a/learn/page/4/index.html
+++ b/learn/page/4/index.html
@@ -3744,7 +3744,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/learn/page/5/index.html b/learn/page/5/index.html
index f1892091a..9d7b26d79 100644
--- a/learn/page/5/index.html
+++ b/learn/page/5/index.html
@@ -3743,7 +3743,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/learn/quickstart/index.html b/learn/quickstart/index.html
index b69640e0d..0f9ba7bc2 100644
--- a/learn/quickstart/index.html
+++ b/learn/quickstart/index.html
@@ -3753,7 +3753,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/learn/sandbox/index.html b/learn/sandbox/index.html
index b25679166..e9ebd3e17 100644
--- a/learn/sandbox/index.html
+++ b/learn/sandbox/index.html
@@ -3745,7 +3745,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/learn/secrets-management-in-the-validated-patterns-framework/index.html b/learn/secrets-management-in-the-validated-patterns-framework/index.html
index d969cdd80..fc9233519 100644
--- a/learn/secrets-management-in-the-validated-patterns-framework/index.html
+++ b/learn/secrets-management-in-the-validated-patterns-framework/index.html
@@ -4094,7 +4094,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/learn/secrets/index.html b/learn/secrets/index.html
index fd567e791..3db2313d6 100644
--- a/learn/secrets/index.html
+++ b/learn/secrets/index.html
@@ -3744,7 +3744,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/learn/test-artifacts/index.html b/learn/test-artifacts/index.html
index 842514af4..0cd785f8a 100644
--- a/learn/test-artifacts/index.html
+++ b/learn/test-artifacts/index.html
@@ -3792,7 +3792,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/learn/tested/index.html b/learn/tested/index.html
index 34c2cac1a..82a6b04ce 100644
--- a/learn/tested/index.html
+++ b/learn/tested/index.html
@@ -3746,7 +3746,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/learn/using-validated-pattern-operator/index.html b/learn/using-validated-pattern-operator/index.html
index 64828948d..1f88fe53e 100644
--- a/learn/using-validated-pattern-operator/index.html
+++ b/learn/using-validated-pattern-operator/index.html
@@ -3745,7 +3745,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/learn/validated_patterns_frameworks/index.html b/learn/validated_patterns_frameworks/index.html
index 2112f7c7d..301f8290d 100644
--- a/learn/validated_patterns_frameworks/index.html
+++ b/learn/validated_patterns_frameworks/index.html
@@ -3744,7 +3744,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/learn/values-files/index.html b/learn/values-files/index.html
index a1264c9be..f5189f0fe 100644
--- a/learn/values-files/index.html
+++ b/learn/values-files/index.html
@@ -3757,7 +3757,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/learn/vault/index.html b/learn/vault/index.html
index dd0b687a9..4268bb026 100644
--- a/learn/vault/index.html
+++ b/learn/vault/index.html
@@ -3768,7 +3768,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/learn/vp_agof/index.html b/learn/vp_agof/index.html
index 4a564d720..8e52e474b 100644
--- a/learn/vp_agof/index.html
+++ b/learn/vp_agof/index.html
@@ -3787,7 +3787,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/learn/vp_agof_config_controller/index.html b/learn/vp_agof_config_controller/index.html
index 905ee4a1e..76fd96c07 100644
--- a/learn/vp_agof_config_controller/index.html
+++ b/learn/vp_agof_config_controller/index.html
@@ -3828,7 +3828,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/learn/vp_openshift_framework/index.html b/learn/vp_openshift_framework/index.html
index 3c1c2d14a..757f6df95 100644
--- a/learn/vp_openshift_framework/index.html
+++ b/learn/vp_openshift_framework/index.html
@@ -3896,7 +3896,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/learn/vp_structure_vp_pattern/index.html b/learn/vp_structure_vp_pattern/index.html
index 8db7a40f9..112ab59ef 100644
--- a/learn/vp_structure_vp_pattern/index.html
+++ b/learn/vp_structure_vp_pattern/index.html
@@ -3744,7 +3744,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/learn/workflow/index.html b/learn/workflow/index.html
index abadc9295..f667667ed 100644
--- a/learn/workflow/index.html
+++ b/learn/workflow/index.html
@@ -3764,7 +3764,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/ansible-edge-gitops-kasten/ansible-automation-platform/index.html b/patterns/ansible-edge-gitops-kasten/ansible-automation-platform/index.html
index 4e055c9e8..d715fe11d 100644
--- a/patterns/ansible-edge-gitops-kasten/ansible-automation-platform/index.html
+++ b/patterns/ansible-edge-gitops-kasten/ansible-automation-platform/index.html
@@ -3773,7 +3773,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/ansible-edge-gitops-kasten/cluster-sizing/index.html b/patterns/ansible-edge-gitops-kasten/cluster-sizing/index.html
index bc54271d5..228bb11cd 100644
--- a/patterns/ansible-edge-gitops-kasten/cluster-sizing/index.html
+++ b/patterns/ansible-edge-gitops-kasten/cluster-sizing/index.html
@@ -3740,7 +3740,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/ansible-edge-gitops-kasten/getting-started/index.html b/patterns/ansible-edge-gitops-kasten/getting-started/index.html
index ccef95296..dcdb06d97 100644
--- a/patterns/ansible-edge-gitops-kasten/getting-started/index.html
+++ b/patterns/ansible-edge-gitops-kasten/getting-started/index.html
@@ -3833,7 +3833,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/ansible-edge-gitops-kasten/ideas-for-customization/index.html b/patterns/ansible-edge-gitops-kasten/ideas-for-customization/index.html
index 9798b1969..e9becb377 100644
--- a/patterns/ansible-edge-gitops-kasten/ideas-for-customization/index.html
+++ b/patterns/ansible-edge-gitops-kasten/ideas-for-customization/index.html
@@ -3933,7 +3933,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/ansible-edge-gitops-kasten/index.html b/patterns/ansible-edge-gitops-kasten/index.html
index 2d9bdff78..aa1bb0c76 100644
--- a/patterns/ansible-edge-gitops-kasten/index.html
+++ b/patterns/ansible-edge-gitops-kasten/index.html
@@ -3742,7 +3742,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/ansible-edge-gitops-kasten/installation-details/index.html b/patterns/ansible-edge-gitops-kasten/installation-details/index.html
index 7c222d837..b7d9a1ac0 100644
--- a/patterns/ansible-edge-gitops-kasten/installation-details/index.html
+++ b/patterns/ansible-edge-gitops-kasten/installation-details/index.html
@@ -3747,7 +3747,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/ansible-edge-gitops-kasten/openshift-virtualization/index.html b/patterns/ansible-edge-gitops-kasten/openshift-virtualization/index.html
index 974bf8636..0ee9e1d4d 100644
--- a/patterns/ansible-edge-gitops-kasten/openshift-virtualization/index.html
+++ b/patterns/ansible-edge-gitops-kasten/openshift-virtualization/index.html
@@ -3945,7 +3945,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/ansible-edge-gitops-kasten/troubleshooting/index.html b/patterns/ansible-edge-gitops-kasten/troubleshooting/index.html
index 02cffea68..b1516a7ff 100644
--- a/patterns/ansible-edge-gitops-kasten/troubleshooting/index.html
+++ b/patterns/ansible-edge-gitops-kasten/troubleshooting/index.html
@@ -3738,7 +3738,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/ansible-edge-gitops-kasten/veeam-kasten/index.html b/patterns/ansible-edge-gitops-kasten/veeam-kasten/index.html
index 25be12e9f..590b12cfb 100644
--- a/patterns/ansible-edge-gitops-kasten/veeam-kasten/index.html
+++ b/patterns/ansible-edge-gitops-kasten/veeam-kasten/index.html
@@ -3748,7 +3748,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/ansible-edge-gitops/ansible-automation-platform/index.html b/patterns/ansible-edge-gitops/ansible-automation-platform/index.html
index 57839adb5..c7b236fb7 100644
--- a/patterns/ansible-edge-gitops/ansible-automation-platform/index.html
+++ b/patterns/ansible-edge-gitops/ansible-automation-platform/index.html
@@ -3773,7 +3773,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/ansible-edge-gitops/cluster-sizing/index.html b/patterns/ansible-edge-gitops/cluster-sizing/index.html
index cc7302fa7..41e52422f 100644
--- a/patterns/ansible-edge-gitops/cluster-sizing/index.html
+++ b/patterns/ansible-edge-gitops/cluster-sizing/index.html
@@ -3740,7 +3740,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/ansible-edge-gitops/getting-started/index.html b/patterns/ansible-edge-gitops/getting-started/index.html
index edccc22b3..183c16ad3 100644
--- a/patterns/ansible-edge-gitops/getting-started/index.html
+++ b/patterns/ansible-edge-gitops/getting-started/index.html
@@ -3804,7 +3804,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/ansible-edge-gitops/ideas-for-customization/index.html b/patterns/ansible-edge-gitops/ideas-for-customization/index.html
index aa5b80cd1..2a8c3d6b0 100644
--- a/patterns/ansible-edge-gitops/ideas-for-customization/index.html
+++ b/patterns/ansible-edge-gitops/ideas-for-customization/index.html
@@ -3933,7 +3933,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/ansible-edge-gitops/index.html b/patterns/ansible-edge-gitops/index.html
index 486a87379..210317eb3 100644
--- a/patterns/ansible-edge-gitops/index.html
+++ b/patterns/ansible-edge-gitops/index.html
@@ -3742,7 +3742,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/ansible-edge-gitops/installation-details/index.html b/patterns/ansible-edge-gitops/installation-details/index.html
index a826a4335..0819624bd 100644
--- a/patterns/ansible-edge-gitops/installation-details/index.html
+++ b/patterns/ansible-edge-gitops/installation-details/index.html
@@ -3747,7 +3747,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/ansible-edge-gitops/openshift-virtualization/index.html b/patterns/ansible-edge-gitops/openshift-virtualization/index.html
index bf195006d..cfe21981e 100644
--- a/patterns/ansible-edge-gitops/openshift-virtualization/index.html
+++ b/patterns/ansible-edge-gitops/openshift-virtualization/index.html
@@ -3945,7 +3945,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/ansible-edge-gitops/troubleshooting/index.html b/patterns/ansible-edge-gitops/troubleshooting/index.html
index 111de5501..687d78b78 100644
--- a/patterns/ansible-edge-gitops/troubleshooting/index.html
+++ b/patterns/ansible-edge-gitops/troubleshooting/index.html
@@ -3738,7 +3738,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/ansible-gitops-framework/index.html b/patterns/ansible-gitops-framework/index.html
index c2379ec41..30a7cb6fb 100644
--- a/patterns/ansible-gitops-framework/index.html
+++ b/patterns/ansible-gitops-framework/index.html
@@ -3742,7 +3742,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/cockroachdb/index.html b/patterns/cockroachdb/index.html
index 14e12d515..0b4376834 100644
--- a/patterns/cockroachdb/index.html
+++ b/patterns/cockroachdb/index.html
@@ -3739,7 +3739,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/coco-pattern/coco-pattern-azure-requirements/index.html b/patterns/coco-pattern/coco-pattern-azure-requirements/index.html
index 9e39786e5..a14f5b3b4 100644
--- a/patterns/coco-pattern/coco-pattern-azure-requirements/index.html
+++ b/patterns/coco-pattern/coco-pattern-azure-requirements/index.html
@@ -3760,7 +3760,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/coco-pattern/coco-pattern-getting-started/index.html b/patterns/coco-pattern/coco-pattern-getting-started/index.html
index d11c1c46b..57d9ab3ad 100644
--- a/patterns/coco-pattern/coco-pattern-getting-started/index.html
+++ b/patterns/coco-pattern/coco-pattern-getting-started/index.html
@@ -3743,7 +3743,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/coco-pattern/index.html b/patterns/coco-pattern/index.html
index 1cd85c760..904bfd835 100644
--- a/patterns/coco-pattern/index.html
+++ b/patterns/coco-pattern/index.html
@@ -3743,7 +3743,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/connected-vehicle-architecture/index.html b/patterns/connected-vehicle-architecture/index.html
index a514d38b8..2be8afdf8 100644
--- a/patterns/connected-vehicle-architecture/index.html
+++ b/patterns/connected-vehicle-architecture/index.html
@@ -3739,7 +3739,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/devsecops/cluster-sizing/index.html b/patterns/devsecops/cluster-sizing/index.html
index 2fc7e85ad..24430c65b 100644
--- a/patterns/devsecops/cluster-sizing/index.html
+++ b/patterns/devsecops/cluster-sizing/index.html
@@ -3746,7 +3746,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/devsecops/devel-cluster/index.html b/patterns/devsecops/devel-cluster/index.html
index cd903fa00..e1b0adc4a 100644
--- a/patterns/devsecops/devel-cluster/index.html
+++ b/patterns/devsecops/devel-cluster/index.html
@@ -3753,7 +3753,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/devsecops/getting-started/index.html b/patterns/devsecops/getting-started/index.html
index 92404adf7..b85c16f28 100644
--- a/patterns/devsecops/getting-started/index.html
+++ b/patterns/devsecops/getting-started/index.html
@@ -3779,7 +3779,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/devsecops/ideas-for-customization/index.html b/patterns/devsecops/ideas-for-customization/index.html
index ec0da082a..d98fd7c11 100644
--- a/patterns/devsecops/ideas-for-customization/index.html
+++ b/patterns/devsecops/ideas-for-customization/index.html
@@ -3738,7 +3738,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/devsecops/index.html b/patterns/devsecops/index.html
index 4c643d36c..0000476f3 100644
--- a/patterns/devsecops/index.html
+++ b/patterns/devsecops/index.html
@@ -3742,7 +3742,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/devsecops/production-cluster/index.html b/patterns/devsecops/production-cluster/index.html
index 19494ed93..3cb1ae130 100644
--- a/patterns/devsecops/production-cluster/index.html
+++ b/patterns/devsecops/production-cluster/index.html
@@ -3751,7 +3751,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/devsecops/secure-supply-chain-demo/index.html b/patterns/devsecops/secure-supply-chain-demo/index.html
index 73fbc9567..9d5945d81 100644
--- a/patterns/devsecops/secure-supply-chain-demo/index.html
+++ b/patterns/devsecops/secure-supply-chain-demo/index.html
@@ -3738,7 +3738,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/emerging-disease-detection/edd-getting-started/index.html b/patterns/emerging-disease-detection/edd-getting-started/index.html
index da10b520c..4bf9ca369 100644
--- a/patterns/emerging-disease-detection/edd-getting-started/index.html
+++ b/patterns/emerging-disease-detection/edd-getting-started/index.html
@@ -3799,7 +3799,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/emerging-disease-detection/index.html b/patterns/emerging-disease-detection/index.html
index a84c3f333..c1bc8a229 100644
--- a/patterns/emerging-disease-detection/index.html
+++ b/patterns/emerging-disease-detection/index.html
@@ -3743,7 +3743,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/gaudi-rag-chat-qna/gaudi-rag-chat-qna-getting-started/index.html b/patterns/gaudi-rag-chat-qna/gaudi-rag-chat-qna-getting-started/index.html
index 218b31c10..eb65bad27 100644
--- a/patterns/gaudi-rag-chat-qna/gaudi-rag-chat-qna-getting-started/index.html
+++ b/patterns/gaudi-rag-chat-qna/gaudi-rag-chat-qna-getting-started/index.html
@@ -3783,7 +3783,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/gaudi-rag-chat-qna/gaudi-rag-chat-qna-required-hardware/index.html b/patterns/gaudi-rag-chat-qna/gaudi-rag-chat-qna-required-hardware/index.html
index be88f97ec..0d46ca191 100644
--- a/patterns/gaudi-rag-chat-qna/gaudi-rag-chat-qna-required-hardware/index.html
+++ b/patterns/gaudi-rag-chat-qna/gaudi-rag-chat-qna-required-hardware/index.html
@@ -3738,7 +3738,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/gaudi-rag-chat-qna/gaudi-rag-chat-qna-troubleshooting/index.html b/patterns/gaudi-rag-chat-qna/gaudi-rag-chat-qna-troubleshooting/index.html
index ef0c5406e..fd3ad26a4 100644
--- a/patterns/gaudi-rag-chat-qna/gaudi-rag-chat-qna-troubleshooting/index.html
+++ b/patterns/gaudi-rag-chat-qna/gaudi-rag-chat-qna-troubleshooting/index.html
@@ -3738,7 +3738,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/gaudi-rag-chat-qna/index.html b/patterns/gaudi-rag-chat-qna/index.html
index d86e87603..2ce2b547a 100644
--- a/patterns/gaudi-rag-chat-qna/index.html
+++ b/patterns/gaudi-rag-chat-qna/index.html
@@ -3742,7 +3742,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/hypershift/index.html b/patterns/hypershift/index.html
index 5ac94e48c..f9303678f 100644
--- a/patterns/hypershift/index.html
+++ b/patterns/hypershift/index.html
@@ -3741,7 +3741,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/index.html b/patterns/index.html
index 20c7e50cd..33f42dd97 100644
--- a/patterns/index.html
+++ b/patterns/index.html
@@ -82,7 +82,7 @@
 </label><label class="pf-c-check pf-c-select__menu-item" for=other_products:portworx-enterprise><input class=pf-c-check__input type=checkbox id=other_products:portworx-enterprise onclick=filterSelection(this.id) name="Portworx Enterprise">
 <span class="pf-c-check__label wrappable">Portworx Enterprise</span>
 </label><label class="pf-c-check pf-c-select__menu-item" for=other_products:veeam-kasten><input class=pf-c-check__input type=checkbox id=other_products:veeam-kasten onclick=filterSelection(this.id) name="Veeam Kasten">
-<span class="pf-c-check__label wrappable">Veeam Kasten</span></label></fieldset></div></div></div></div></div></div></div></div></div><main class=pf-c-page__main><section class=pf-c-page__main-section><div class="pf-l-grid__item pf-m-9-col"><div class=pf-u-text-align-center><div class=pf-c-content style=--pf-c-content--FontSize:1rem><h1 class="pf-c-title pf-m-4xl">Patterns</h1><div class=page-abstract><p>Browse through available patterns and their respective documentation for deployment and operation. Filter patterns by type, industry, and product.</p></div></div></div><div class=pf-c-content><div class="pf-l-stack pf-m-gutter"><div class="pf-l-stack__item pf-u-text-align-right pattern-count-style"><span id=pattern-count>26</span> of 26 patterns displayed</div><div class=pf-l-stack__item><div class="pf-l-gallery pf-m-gutter" style=--pf-l-gallery--GridTemplateColumns--min:300px><div class="pf-l-gallery__item filterDiv" tag-data="industries:general rh_products:red-hat-openshift-container-platform rh_products:red-hat-openshift-gitops type:tested" style=display:grid><div class=pf-c-card style=text-align:left;--pf-c-card__title--FontSize:1rem;--pf-c-card__body--FontSize:0.95rem><div class=pf-c-card__title><a href=/patterns/rag-llm-gitops/>AI Generation with LLM and RAG</a></div><div class=pf-c-card__body>The goal of this demo is to demonstrate a Chatbot LLM application augmented with data from Red Hat product documentation running on Red Hat OpenShift. It deploys an LLM application that connects to multiple LLM providers such as OpenAI, Hugging Face, and NVIDIA NIM. The application generates a project proposal for a Red Hat product.</div><div class=pf-c-card__footer><span class="pf-c-label pf-m-blue"><span class=pf-c-label__content><img src=/images/pattern-tier-tested.png alt=Tested width=16 height=16 class=custom-pattern-icon>
+<span class="pf-c-check__label wrappable">Veeam Kasten</span></label></fieldset></div></div></div></div></div></div></div></div></div><main class=pf-c-page__main><section class=pf-c-page__main-section><div class="pf-l-grid__item pf-m-9-col"><div class=pf-u-text-align-center><div class=pf-c-content style=--pf-c-content--FontSize:1rem><h1 class="pf-c-title pf-m-4xl">Patterns</h1><div class=page-abstract><p>Browse through available patterns and their respective documentation for deployment and operation. Filter patterns by type, industry, and product.</p></div></div></div><div class=pf-c-content><div class="pf-l-stack pf-m-gutter"><div class="pf-l-stack__item pf-u-text-align-right pattern-count-style"><span id=pattern-count>27</span> of 27 patterns displayed</div><div class=pf-l-stack__item><div class="pf-l-gallery pf-m-gutter" style=--pf-l-gallery--GridTemplateColumns--min:300px><div class="pf-l-gallery__item filterDiv" tag-data="industries:general rh_products:red-hat-openshift-container-platform rh_products:red-hat-openshift-gitops type:tested" style=display:grid><div class=pf-c-card style=text-align:left;--pf-c-card__title--FontSize:1rem;--pf-c-card__body--FontSize:0.95rem><div class=pf-c-card__title><a href=/patterns/rag-llm-gitops/>AI Generation with LLM and RAG</a></div><div class=pf-c-card__body>The goal of this demo is to demonstrate a Chatbot LLM application augmented with data from Red Hat product documentation running on Red Hat OpenShift. It deploys an LLM application that connects to multiple LLM providers such as OpenAI, Hugging Face, and NVIDIA NIM. The application generates a project proposal for a Red Hat product.</div><div class=pf-c-card__footer><span class="pf-c-label pf-m-blue"><span class=pf-c-label__content><img src=/images/pattern-tier-tested.png alt=Tested width=16 height=16 class=custom-pattern-icon>
 Tested</span></span></div></div></div><div class="pf-l-gallery__item filterDiv" tag-data="industries:chemical rh_products:red-hat-openshift-container-platform rh_products:red-hat-ansible-automation-platform rh_products:red-hat-openshift-virtualization rh_products:red-hat-enterprise-linux rh_products:red-hat-openshift-data-foundation type:maintained" style=display:grid><div class=pf-c-card style=text-align:left;--pf-c-card__title--FontSize:1rem;--pf-c-card__body--FontSize:0.95rem><div class=pf-c-card__title><a href=/patterns/ansible-edge-gitops/>Ansible Edge GitOps</a></div><div class=pf-c-card__body>This pattern uses OpenShift Virtualization to simulate an edge environment for VMs.</div><div class=pf-c-card__footer><span class="pf-c-label pf-m-green"><span class=pf-c-label__content><img src=/images/pattern-tier-maintained.png alt=Maintained width=16 height=16 class=custom-pattern-icon>
 Maintained</span></span></div></div></div><div class="pf-l-gallery__item filterDiv" tag-data="industries:chemical other_products:veeam-kasten rh_products:red-hat-openshift-container-platform rh_products:red-hat-ansible-automation-platform rh_products:red-hat-openshift-virtualization rh_products:red-hat-enterprise-linux rh_products:red-hat-openshift-data-foundation type:sandbox" style=display:grid><div class=pf-c-card style=text-align:left;--pf-c-card__title--FontSize:1rem;--pf-c-card__body--FontSize:0.95rem><div class=pf-c-card__title><a href=/patterns/ansible-edge-gitops-kasten/>Ansible Edge GitOps with Veeam Kasten</a></div><div class=pf-c-card__body>This pattern uses OpenShift Virtualization to simulate an edge environment for VMs, protected by Veeam Kasten.</div><div class=pf-c-card__footer><span class="pf-c-label pf-m-orange"><span class=pf-c-label__content><img src=/images/pattern-tier-sandbox.png alt=Sandbox width=16 height=16 class=custom-pattern-icon>
 Sandbox</span></span></div></div></div><div class="pf-l-gallery__item filterDiv" tag-data="rh_products:red-hat-ansible-automation-platform rh_products:red-hat-enterprise-linux type:sandbox" style=display:grid><div class=pf-c-card style=text-align:left;--pf-c-card__title--FontSize:1rem;--pf-c-card__body--FontSize:0.95rem><div class=pf-c-card__title><a href=/patterns/ansible-gitops-framework/>Ansible GitOps Framework</a></div><div class=pf-c-card__body>This variant of the Validated Patterns framework exists to support GitOps outside of Kubernetes.</div><div class=pf-c-card__footer><span class="pf-c-label pf-m-orange"><span class=pf-c-label__content><img src=/images/pattern-tier-sandbox.png alt=Sandbox width=16 height=16 class=custom-pattern-icon>
@@ -106,6 +106,7 @@
 Sandbox</span></span></div></div></div><div class="pf-l-gallery__item filterDiv" tag-data="industries:general rh_products:red-hat-openshift-container-platform rh_products:red-hat-advanced-cluster-management rh_products:red-hat-quay rh_products:red-hat-openshift-data-foundation rh_products:red-hat-advanced-cluster-security type:sandbox" style=display:grid><div class=pf-c-card style=text-align:left;--pf-c-card__title--FontSize:1rem;--pf-c-card__body--FontSize:0.95rem><div class=pf-c-card__title><a href=/patterns/devsecops/>Multicluster DevSecOps</a></div><div class=pf-c-card__body>This pattern is derived from the multi-cloud GitOps pattern with added products to provide a complete DevSecOps workflow.</div><div class=pf-c-card__footer><span class="pf-c-label pf-m-orange"><span class=pf-c-label__content><img src=/images/pattern-tier-sandbox.png alt=Sandbox width=16 height=16 class=custom-pattern-icon>
 Sandbox</span></span></div></div></div><div class="pf-l-gallery__item filterDiv" tag-data="industries:general rh_products:red-hat-openshift-container-platform rh_products:red-hat-openshift-data-foundation rh_products:red-hat-openshift-ai rh_products:red-hat-openshift-serverless rh_products:red-hat-openshift-service-mesh type:sandbox" style=display:grid><div class=pf-c-card style=text-align:left;--pf-c-card__title--FontSize:1rem;--pf-c-card__body--FontSize:0.95rem><div class=pf-c-card__title><a href=/patterns/gaudi-rag-chat-qna/>OPEA QnA chat accelerated with Intel Gaudi</a></div><div class=pf-c-card__body>This pattern helps you deploy stack enabling Intel Gaudi Accelerator and it also deploys RAG application - Chat QnA</div><div class=pf-c-card__footer><span class="pf-c-label pf-m-orange"><span class=pf-c-label__content><img src=/images/pattern-tier-sandbox.png alt=Sandbox width=16 height=16 class=custom-pattern-icon>
 Sandbox</span></span></div></div></div><div class="pf-l-gallery__item filterDiv" tag-data="industries:general rh_products:red-hat-openshift-container-platform rh_products:red-hat-openshift-ai rh_products:red-hat-pipelines type:sandbox" style=display:grid><div class=pf-c-card style=text-align:left;--pf-c-card__title--FontSize:1rem;--pf-c-card__body--FontSize:0.95rem><div class=pf-c-card__title><a href=/patterns/openshift-ai/>OpenShift AI</a></div><div class=pf-c-card__body>This pattern is a starting point for using Red Hat OpenShift AI.</div><div class=pf-c-card__footer><span class="pf-c-label pf-m-orange"><span class=pf-c-label__content><img src=/images/pattern-tier-sandbox.png alt=Sandbox width=16 height=16 class=custom-pattern-icon>
+Sandbox</span></span></div></div></div><div class="pf-l-gallery__item filterDiv" tag-data="rh_products:red-hat-openshift-container-platform type:sandbox" style=display:grid><div class=pf-c-card style=text-align:left;--pf-c-card__title--FontSize:1rem;--pf-c-card__body--FontSize:0.95rem><div class=pf-c-card__title><a href=/patterns/regional-dr/>Regional Disaster Recovery</a></div><div class=pf-c-card__body>This variant of the Validated Patterns framework deploys a Regional Disaster Recovery Setup across multiple different regions</div><div class=pf-c-card__footer><span class="pf-c-label pf-m-orange"><span class=pf-c-label__content><img src=/images/pattern-tier-sandbox.png alt=Sandbox width=16 height=16 class=custom-pattern-icon>
 Sandbox</span></span></div></div></div><div class="pf-l-gallery__item filterDiv" tag-data="industries:retail rh_products:red-hat-openshift-container-platform rh_products:red-hat-advanced-cluster-management rh_products:red-hat-amq type:tested" style=display:grid><div class=pf-c-card style=text-align:left;--pf-c-card__title--FontSize:1rem;--pf-c-card__body--FontSize:0.95rem><div class=pf-c-card__title><a href=/patterns/retail/>Retail</a></div><div class=pf-c-card__body>This pattern demonstrates a pattern that models the store side of a retail application.</div><div class=pf-c-card__footer><span class="pf-c-label pf-m-blue"><span class=pf-c-label__content><img src=/images/pattern-tier-tested.png alt=Tested width=16 height=16 class=custom-pattern-icon>
 Tested</span></span></div></div></div><div class="pf-l-gallery__item filterDiv" tag-data="industries:general rh_products:red-hat-openshift-container-platform rh_products:red-hat-service-mesh rh_products:red-hat-kiali rh_products:red-hat-jaeger-distributed-tracing rh_products:red-hat-elasticsearch type:tested" style=display:grid><div class=pf-c-card style=text-align:left;--pf-c-card__title--FontSize:1rem;--pf-c-card__body--FontSize:0.95rem><div class=pf-c-card__title><a href=/patterns/travelops/>TravelOps</a></div><div class=pf-c-card__body>This pattern enables you to secure your applications using Red Hat Service Mesh.</div><div class=pf-c-card__footer><span class="pf-c-label pf-m-blue"><span class=pf-c-label__content><img src=/images/pattern-tier-tested.png alt=Tested width=16 height=16 class=custom-pattern-icon>
 Tested</span></span></div></div></div></div></div></div></div></div><script src=/js/filter.js></script></section><section id=prefooter class="pf-c-page__main-section footer-dark"><div class="pf-l-grid prefooter-menu-grid"><div class="pf-l-grid__item pf-m-12-col-on-sm pf-m-6-col-on-md pf-m-offset-1-col-on-md pf-u-mb-lg pf-u-mb-0-on-sm"><div class="pf-l-grid pf-u-py-xl"><div class="pf-l-grid__item pf-m-6-col-on-sm pf-m-4-col-on-md pf-u-ml-md pf-u-ml-0-on-md pf-u-mb-xl pf-u-mb-0-on-md"><p class="pf-c-title footer-menu-title">QUICKLINKS</p><nav aria-label="Quick Links"><ul class="pf-c-list pf-m-plain"><li><i class="prefooter-icon fa-brands fa-github"></i>
@@ -3844,7 +3845,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/index.json b/patterns/index.json
index 6934a83cf..6c7e9b17c 100644
--- a/patterns/index.json
+++ b/patterns/index.json
@@ -1 +1 @@
-[{"AI Generation with LLM and RAG":{"aliases":["/ai/"],"ci":"ai","date":"2024-07-25T00:00:00Z","draft":false,"industries":["General"],"iscjklanguage":false,"lastmod":"2024-07-25T00:00:00Z","links":{"bugs":"https://github.com/validatedpatterns/rag-llm-gitops/issues","help":"https://groups.google.com/g/validatedpatterns","install":"getting-started"},"publishdate":"2024-07-25T00:00:00Z","rh_products":["Red Hat OpenShift Container Platform","Red Hat OpenShift GitOps"],"summary":"The goal of this demo is to demonstrate a Chatbot LLM application augmented with data from Red Hat product documentation running on Red Hat OpenShift. It deploys an LLM application that connects to multiple LLM providers such as OpenAI, Hugging Face, and NVIDIA NIM. The application generates a project proposal for a Red Hat product.","tier":"tested","title":"AI Generation with LLM and RAG"}},{"Ansible Edge GitOps":{"aliases":["/ansible-edge-gitops/"],"ci":"aegitops","date":"2022-06-08T00:00:00Z","draft":false,"industries":["Chemical"],"iscjklanguage":false,"lastmod":"2022-06-08T00:00:00Z","links":{"bugs":"https://github.com/validatedpatterns/ansible-edge-gitops/issues","help":"https://groups.google.com/g/validatedpatterns","install":"getting-started"},"pattern_logo":"ansible-edge.png","publishdate":"2022-06-08T00:00:00Z","rh_products":["Red Hat OpenShift Container Platform","Red Hat Ansible Automation Platform","Red Hat OpenShift Virtualization","Red Hat Enterprise Linux","Red Hat OpenShift Data Foundation"],"summary":"This pattern uses OpenShift Virtualization to simulate an edge environment for VMs.","tier":"maintained","title":"Ansible Edge GitOps"}},{"Ansible Edge GitOps with Veeam Kasten":{"aliases":["/ansible-edge-gitops-kasten/"],"date":"2024-10-28T00:00:00Z","draft":false,"industries":["Chemical"],"iscjklanguage":false,"lastmod":"2024-10-28T00:00:00Z","links":{"bugs":"https://github.com/validatedpatterns/ansible-edge-gitops/issues","help":"https://groups.google.com/g/validatedpatterns","install":"getting-started"},"other_products":["Veeam Kasten"],"pattern_logo":"veeam-kasten.png","publishdate":"2024-10-28T00:00:00Z","rh_products":["Red Hat OpenShift Container Platform","Red Hat Ansible Automation Platform","Red Hat OpenShift Virtualization","Red Hat Enterprise Linux","Red Hat OpenShift Data Foundation"],"summary":"This pattern uses OpenShift Virtualization to simulate an edge environment for VMs, protected by Veeam Kasten.","tier":"sandbox","title":"Ansible Edge GitOps with Veeam Kasten"}},{"Ansible GitOps Framework":{"aliases":["/agof/"],"date":"2024-06-13T00:00:00Z","draft":false,"industries":null,"iscjklanguage":false,"lastmod":"2024-06-13T00:00:00Z","links":{"bugs":"https://github.com/validatedpatterns/agof/issues","help":"https://groups.google.com/g/validatedpatterns","install":"https://github.com/validatedpatterns/agof/"},"pattern_logo":"ansible-edge.png","publishdate":"2024-06-13T00:00:00Z","rh_products":["Red Hat Ansible Automation Platform","Red Hat Enterprise Linux"],"summary":"This variant of the Validated Patterns framework exists to support GitOps outside of Kubernetes.","tier":"sandbox","title":"Ansible GitOps Framework"}},{"Cockroach":{"draft":false,"iscjklanguage":false,"rh_products":["Red Hat OpenShift Container Platform","Red Hat Advanced Cluster Management"],"summary":"A multicloud pattern using cockroachdb and submariner, deployed via RHACM.","tier":"sandbox","title":"Cockroach"}},{"Confidential Containers pattern":{"aliases":["/coco-pattern/"],"date":"2024-10-03T00:00:00Z","draft":false,"industries":["General"],"iscjklanguage":false,"lastmod":"2024-10-03T00:00:00Z","links":{"bugs":"https://github.com/validatedpatterns/coco-pattern/issues","help":"https://groups.google.com/g/validatedpatterns","install":"coco-getting-started"},"pattern_logo":"coco-logo.png","publishdate":"2024-10-03T00:00:00Z","rh_products":["Red Hat OpenShift Container Platform","Red Hat Advanced Cluster Management","Red Hat OpenShift Sandbox Containers"],"summary":"This pattern helps you get started with deploying confidential containers in OpenShift Container Platform.","tier":"sandbox","title":"Confidential Containers pattern"}},{"Connected Vehicle Architecture":{"draft":false,"iscjklanguage":false,"rh_products":["Red Hat OpenShift Container Platform","Red Hat Ansible Automation Platform"],"summary":"A distributed cloud-native application that implements key aspects of a modern IoT architecture.","tier":"sandbox","title":"Connected Vehicle Architecture"}},{"Emerging Disease Detection":{"// pattern_logo":"emerging-disease-detection.png","aliases":["/emerging-disease-detection/"],"ci":"edd","contributor":{"contact":"mailto:anattama@redhat.com","git":"https://github.com/arunhari82","name":"Arunkumar Nattamai Hariharan"},"date":"2023-09-23T00:00:00Z","draft":false,"industries":["medical"],"iscjklanguage":false,"lastmod":"2023-09-23T00:00:00Z","links":{"arch":"https://www.redhat.com/architect/portfolio/detail/6-enabling-medical-imaging-diagnostics-with-edge","bugs":"https://github.com/validatedpatterns/emerging-disease-detection/issues","help":"https://groups.google.com/g/validatedpatterns","install":"edd-getting-started"},"publishdate":"2023-09-23T00:00:00Z","rh_products":["Red Hat OpenShift Container Platform","Red Hat OpenShift Serverless","Red Hat Single Sign-On","Red Hat AMQ Streams"],"summary":"This pattern is based on a demo implementation of an automated data pipeline for sepsis analysis previously developed by Red Hat.","tier":"sandbox","title":"Emerging Disease Detection"}},{"HyperShift":{"aliases":["/hypershift/"],"ci":"hypershift","date":"2023-11-15T00:00:00Z","draft":false,"industries":["Infrastructure"],"iscjklanguage":false,"lastmod":"2023-11-15T00:00:00Z","links":{"bugs":"https://github.com/validatedpatterns-sandbox/hypershift/issues","help":"https://groups.google.com/g/validatedpatterns"},"other_products":["AWS Controller for Kubernetes"],"pattern_logo":"medical-diagnosis.png","publishdate":"2023-11-15T00:00:00Z","rh_products":["Red Hat OpenShift Container Platform","Red Hat MultiCluster Engine"],"summary":"This pattern is for deploying the Hosted Control Plane (HyperShift) service.","tier":"sandbox","title":"HyperShift"}},{"Industrial Edge":{"aliases":["/industrial-edge/"],"ci":"manuela","date":"2021-10-12T00:00:00Z","draft":false,"industries":["Industrial","Manufacturing"],"iscjklanguage":false,"lastmod":"2021-10-12T00:00:00Z","links":{"arch":"https://www.redhat.com/architect/portfolio/detail/26-industrial-edge","bugs":"https://github.com/validatedpatterns/industrial-edge/issues","help":"https://groups.google.com/g/validatedpatterns","install":"getting-started"},"pattern_logo":"industrial-edge.png","publishdate":"2021-10-12T00:00:00Z","rh_products":["Red Hat OpenShift Container Platform","Red Hat Advanced Cluster Management","Red Hat Quay","Red Hat AMQ"],"summary":"This pattern demonstrates a horizontal solution for Industrial Edge use cases.","tier":"maintained","title":"Industrial Edge"}},{"Intel AMX accelerated Medical Diagnosis":{"aliases":["/medical-diagnosis-amx/"],"date":"2023-10-10T00:00:00Z","draft":false,"industries":["medical"],"iscjklanguage":false,"lastmod":"2023-10-10T00:00:00Z","links":{"arch":"https://www.redhat.com/architect/portfolio/detail/6-enabling-medical-imaging-diagnostics-with-edge","bugs":"https://github.com/validatedpatterns-sandbox/amx-accelerated-medical-diagnosis/issues","help":"https://groups.google.com/g/hybrid-cloud-patterns","install":"getting-started"},"pattern_logo":"medical-diagnosis.png","products":["Red Hat OpenShift Container Platform","Red Hat OpenShift Serverless","Red Hat OpenShift Data Foundation","Red Hat OpenShift Node Feature Discovery","4th Gen Intel Xeon Scalable processors with Intel Advanced Matrix Extensions (Intel AMX)"],"publishdate":"2023-10-10T00:00:00Z","summary":"This pattern is based on a demo implementation of an automated data pipeline for chest X-ray analysis previously developed by Red Hat. The pattern is modified to utilize Intel AMX feature.","title":"Intel AMX accelerated Medical Diagnosis","validated":false}},{"Intel AMX accelerated Multicloud GitOps":{"aliases":["/multicloud-gitops-amx/"],"date":"2023-10-05T00:00:00Z","draft":false,"industries":["General"],"iscjklanguage":false,"lastmod":"2023-10-05T00:00:00Z","links":{"bugs":"https://github.com/validatedpatterns-sandbox/amx-accelerated-multicloud-gitops/issues","help":"https://groups.google.com/g/hybrid-cloud-patterns","install":"mcg-amx-getting-started"},"pattern_logo":"amx-intel-ai.png","products":["Red Hat OpenShift Container Platform","Red Hat Advanced Cluster Management","Red Hat Node Feature Discovery","4th Gen Intel Xeon Scalable processors with Intel Advanced Matrix Extensions (Intel AMX)"],"publishdate":"2023-10-05T00:00:00Z","summary":"This is extension of Multicloud GitOps pattern with additional application to show the value of using Intel AMX.","title":"Intel AMX accelerated Multicloud GitOps","validated":false}},{"Intel AMX accelerated Multicloud GitOps with Openshift AI":{"aliases":["/multicloud-gitops-amx-rhoai/"],"date":"2024-02-27T00:00:00Z","draft":false,"industries":["General"],"iscjklanguage":false,"lastmod":"2024-02-27T00:00:00Z","links":{"bugs":"https://github.com/validatedpatterns-sandbox/amx-accelerated-multicloud-gitops/issues","help":"https://groups.google.com/g/hybrid-cloud-patterns","install":"mcg-amx-rhoai-getting-started"},"pattern_logo":"amx-intel-ai.png","products":["Red Hat OpenShift Container Platform","Red Hat Advanced Cluster Management","Red Hat Openshift AI","OpenVINO Toolkit Operator","5th Gen Intel Xeon Scalable processors with Intel Advanced Matrix Extensions (Intel AMX)"],"publishdate":"2024-02-27T00:00:00Z","summary":"This is extension of Multicloud GitOps pattern with Red Hat Openshift AI component to show the value of using Intel AMX.","title":"Intel AMX accelerated Multicloud GitOps with Openshift AI","validated":false}},{"Intel QAT accelerated Multicloud GitOps":{"aliases":["/multicloud-gitops-qat/"],"date":"2023-10-05T00:00:00Z","draft":false,"industries":["General"],"iscjklanguage":false,"lastmod":"2023-10-05T00:00:00Z","links":{"bugs":"https://github.com/validatedpatterns-sandbox/qat-accelerated-istio/issues","help":"https://groups.google.com/g/hybrid-cloud-patterns","install":"mcg-qat-getting-started"},"pattern_logo":"intel-qat.png","products":["Red Hat OpenShift Container Platform","Red Hat Advanced Cluster Management","Red Hat Node Feature Discovery","4th Gen Intel Xeon Scalable processors with Intel QuickAssist Technology (Intel QAT)","Sail Operator (Istio Service Mesh)","Intel Device Plugin Operator"],"publishdate":"2023-10-05T00:00:00Z","summary":"This is extension of Multicloud GitOps pattern with additional application to show the value of using Intel QAT.","title":"Intel QAT accelerated Multicloud GitOps","validated":false}},{"Intel SGX protected application in Multicloud GitOps":{"aliases":["/multicloud-gitops-sgx-hello-world/"],"date":"2024-02-20T00:00:00Z","draft":false,"industries":["General"],"iscjklanguage":false,"lastmod":"2024-02-20T00:00:00Z","links":{"help":"https://groups.google.com/g/hybrid-cloud-patterns","install":"mcg-sgx-hello-world-getting-started"},"pattern_logo":"sgx-intel-ai.png","products":["Red Hat OpenShift Container Platform","Red Hat Advanced Cluster Management","Red Hat Node Feature Discovery","Intel Device Plugins Operator","5th Gen Intel Xeon Scalable processors with Intel Software Guard Extensions (Intel SGX)"],"publishdate":"2024-02-20T00:00:00Z","summary":"This is an extension of Multicloud GitOps pattern with additional application using Intel SGX.","title":"Intel SGX protected application in Multicloud GitOps","validated":false}},{"Intel SGX protected Vault for Multicloud GitOps":{"aliases":["/multicloud-gitops-sgx/"],"date":"2024-02-09T00:00:00Z","draft":false,"industries":["General"],"iscjklanguage":false,"lastmod":"2024-02-09T00:00:00Z","links":{"bugs":"https://github.com/validatedpatterns-sandbox/sgx-multicloud-gitops-vault/issues","help":"https://groups.google.com/g/hybrid-cloud-patterns","install":"mcg-sgx-getting-started"},"pattern_logo":"sgx-intel-ai.png","products":["Red Hat OpenShift Container Platform","Red Hat Advanced Cluster Management","Red Hat Node Feature Discovery","Intel Device Plugins","5th Gen Intel Xeon Scalable processors with Intel Security Guard Extensions (Intel SGX)"],"publishdate":"2024-02-09T00:00:00Z","summary":"This is an extension of the Multicloud GitOps pattern with an additional application to show the value of using Intel SGX.","title":"Intel SGX protected Vault for Multicloud GitOps","validated":false}},{"Kong":{"draft":false,"iscjklanguage":false,"rh_products":["Red Hat OpenShift Container Platform"],"summary":"A pattern for Kong Gateway Control Plane and Data Plane demo.","tier":"sandbox","title":"Kong"}},{"Medical Diagnosis":{"aliases":["/medical-diagnosis/"],"ci":"medicaldiag","date":"2021-01-19T00:00:00Z","draft":false,"industries":["medical"],"iscjklanguage":false,"lastmod":"2021-01-19T00:00:00Z","links":{"arch":"https://www.redhat.com/architect/portfolio/detail/6-enabling-medical-imaging-diagnostics-with-edge","bugs":"https://github.com/validatedpatterns/medical-diagnosis/issues","help":"https://groups.google.com/g/validatedpatterns","install":"getting-started"},"pattern_logo":"medical-diagnosis.png","publishdate":"2021-01-19T00:00:00Z","rh_products":["Red Hat OpenShift Container Platform","Red Hat OpenShift Serverless","Red Hat OpenShift Data Foundation"],"summary":"This pattern is based on a demo implementation of an automated data pipeline for chest X-ray analysis previously developed by Red Hat.","tier":"maintained","title":"Medical Diagnosis"}},{"MLOps Fraud Detection":{"aliases":["/mlops-fraud-detection/"],"ci":"mfd","contributor":{"contact":"mailto:arskhan@redhat.com","git":"https://github.com/arslankhanali","name":"Arslan Khan"},"date":"2023-11-12T00:00:00Z","draft":false,"industries":["financial services"],"iscjklanguage":false,"lastmod":"2023-11-12T00:00:00Z","links":{"arch":"https://www.redhat.com/architect/portfolio/architecturedetail?ppid=6","bugs":"https://github.com/validatedpatterns/mlops-fraud-detection/issues","help":"https://groups.google.com/g/validatedpatterns","install":"mfd-getting-started"},"pattern_logo":"mlops-fraud-detection.png","publishdate":"2023-11-12T00:00:00Z","rh_products":["Red Hat OpenShift Container Platform","Red Hat OpenShift Data Science","Red Hat OpenShift Data Foundation"],"summary":"This pattern demonstrates how Red Hat OpenShift Data Science and MLFlow can be used together to build an end-to-end MLOps platform. It demonstrates this using a credit card fraud detection use case.","tier":"sandbox","title":"MLOps Fraud Detection"}},{"Multicloud GitOps":{"aliases":["/multicloud-gitops/"],"ci":"mcgitops","date":"2021-12-11T00:00:00Z","draft":false,"industries":["General"],"iscjklanguage":false,"lastmod":"2021-12-11T00:00:00Z","links":{"arch":"https://www.redhat.com/architect/portfolio/detail/8-hybrid-multicloud-management-with-gitops","bugs":"https://github.com/validatedpatterns/multicloud-gitops/issues","help":"https://groups.google.com/g/validatedpatterns","install":"mcg-getting-started"},"pattern_logo":"multicloud-gitops.png","publishdate":"2021-12-11T00:00:00Z","rh_products":["Red Hat OpenShift Container Platform","Red Hat Advanced Cluster Management"],"summary":"This pattern helps you develop and deploy applications on an open hybrid cloud in a stable, simple, and secure way.","tier":"maintained","title":"Multicloud GitOps"}},{"Multicloud GitOps with Portworx Enterprise":{"aliases":["/multicloud-gitops-Portworx/"],"date":"2023-18-05","draft":false,"industries":["General"],"iscjklanguage":false,"links":{"bugs":"https://github.com/portworx/rh-multicloud-gitops-pxe/issues","help":"https://groups.google.com/g/validatedpatterns","install":"getting-started"},"other_products":["Portworx Enterprise"],"pattern_logo":"multicloud-gitops-Portworx.png","rh_products":["Red Hat OpenShift Container Platform","Red Hat Advanced Cluster Management"],"summary":"This pattern helps you develop and deploy applications on an open hybrid cloud in a stable, simple, and secure way. It includes persistent storage for stateful applications.","tier":"sandbox","title":"Multicloud GitOps with Portworx Enterprise"}},{"Multicluster DevSecOps":{"aliases":["/devsecops/"],"ci":"devsecops","date":"2022-06-08T00:00:00Z","draft":false,"industries":["General"],"iscjklanguage":false,"lastmod":"2022-06-08T00:00:00Z","links":{"bugs":"https://github.com/validatedpatterns/multicluster-devsecops/issues","help":"https://groups.google.com/g/validatedpatterns","install":"getting-started"},"publishdate":"2022-06-08T00:00:00Z","rh_products":["Red Hat OpenShift Container Platform","Red Hat Advanced Cluster Management","Red Hat Quay","Red Hat OpenShift Data Foundation","Red Hat Advanced Cluster Security"],"summary":"This pattern is derived from the multi-cloud GitOps pattern with added products to provide a complete DevSecOps workflow.","tier":"sandbox","title":"Multicluster DevSecOps"}},{"OPEA QnA chat accelerated with Intel Gaudi":{"aliases":["/gaudi-rag-chat-qna/"],"date":"2024-06-01T00:00:00Z","draft":false,"industries":["General"],"iscjklanguage":false,"lastmod":"2024-06-01T00:00:00Z","links":{"bugs":"https://github.com/validatedpatterns-sandbox/","help":"https://groups.google.com/g/hybrid-cloud-patterns","install":"gaudi-rag-chat-qna-getting-started"},"publishdate":"2024-06-01T00:00:00Z","rh_products":["Red Hat OpenShift Container Platform","Red Hat OpenShift Data Foundation","Red Hat OpenShift AI","Red Hat OpenShift Serverless","Red Hat OpenShift Service Mesh"],"summary":"This pattern helps you deploy stack enabling Intel Gaudi Accelerator and it also deploys RAG application - Chat QnA","title":"OPEA QnA chat accelerated with Intel Gaudi","validated":false}},{"OpenShift AI":{"aliases":["/rhoai/"],"ci":"rhoai","date":"2024-04-22T00:00:00Z","draft":false,"industries":["General"],"iscjklanguage":false,"lastmod":"2024-04-22T00:00:00Z","links":{"bugs":"https://github.com/validatedpatterns-sandbox/travelops/issues","help":"https://groups.google.com/g/validatedpatterns","install":"getting-started"},"publishdate":"2024-04-22T00:00:00Z","rh_products":["Red Hat OpenShift Container Platform","Red Hat OpenShift AI","Red Hat Pipelines"],"summary":"This pattern is a starting point for using Red Hat OpenShift AI.","tier":"sandbox","title":"OpenShift AI"}},{"Retail":{"aliases":["/retail/"],"ci":"retail","date":"2022-12-08T00:00:00Z","draft":false,"industries":["Retail"],"iscjklanguage":false,"lastmod":"2022-12-08T00:00:00Z","links":{"bugs":"https://github.com/validatedpatterns/retail/issues","help":"https://groups.google.com/g/validatedpatterns","install":"getting-started"},"publishdate":"2022-12-08T00:00:00Z","rh_products":["Red Hat OpenShift Container Platform","Red Hat Advanced Cluster Management","Red Hat AMQ"],"summary":"This pattern demonstrates a pattern that models the store side of a retail application.","tier":"tested","title":"Retail"}},{"TravelOps":{"aliases":["/travelops/"],"ci":"travelops","date":"2024-02-09T00:00:00Z","draft":false,"industries":["General"],"iscjklanguage":false,"lastmod":"2024-02-09T00:00:00Z","links":{"bugs":"https://github.com/validatedpatterns-sandbox/travelops/issues","help":"https://groups.google.com/g/validatedpatterns","install":"getting-started"},"publishdate":"2024-02-09T00:00:00Z","rh_products":["Red Hat OpenShift Container Platform","Red Hat Service Mesh","Red Hat Kiali","Red Hat Jaeger Distributed Tracing","Red Hat ElasticSearch"],"summary":"This pattern enables you to secure your applications using Red Hat Service Mesh.","tier":"tested","title":"TravelOps"}}]
\ No newline at end of file
+[{"AI Generation with LLM and RAG":{"aliases":["/ai/"],"ci":"ai","date":"2024-07-25T00:00:00Z","draft":false,"industries":["General"],"iscjklanguage":false,"lastmod":"2024-07-25T00:00:00Z","links":{"bugs":"https://github.com/validatedpatterns/rag-llm-gitops/issues","help":"https://groups.google.com/g/validatedpatterns","install":"getting-started"},"publishdate":"2024-07-25T00:00:00Z","rh_products":["Red Hat OpenShift Container Platform","Red Hat OpenShift GitOps"],"summary":"The goal of this demo is to demonstrate a Chatbot LLM application augmented with data from Red Hat product documentation running on Red Hat OpenShift. It deploys an LLM application that connects to multiple LLM providers such as OpenAI, Hugging Face, and NVIDIA NIM. The application generates a project proposal for a Red Hat product.","tier":"tested","title":"AI Generation with LLM and RAG"}},{"Ansible Edge GitOps":{"aliases":["/ansible-edge-gitops/"],"ci":"aegitops","date":"2022-06-08T00:00:00Z","draft":false,"industries":["Chemical"],"iscjklanguage":false,"lastmod":"2022-06-08T00:00:00Z","links":{"bugs":"https://github.com/validatedpatterns/ansible-edge-gitops/issues","help":"https://groups.google.com/g/validatedpatterns","install":"getting-started"},"pattern_logo":"ansible-edge.png","publishdate":"2022-06-08T00:00:00Z","rh_products":["Red Hat OpenShift Container Platform","Red Hat Ansible Automation Platform","Red Hat OpenShift Virtualization","Red Hat Enterprise Linux","Red Hat OpenShift Data Foundation"],"summary":"This pattern uses OpenShift Virtualization to simulate an edge environment for VMs.","tier":"maintained","title":"Ansible Edge GitOps"}},{"Ansible Edge GitOps with Veeam Kasten":{"aliases":["/ansible-edge-gitops-kasten/"],"date":"2024-10-28T00:00:00Z","draft":false,"industries":["Chemical"],"iscjklanguage":false,"lastmod":"2024-10-28T00:00:00Z","links":{"bugs":"https://github.com/validatedpatterns/ansible-edge-gitops/issues","help":"https://groups.google.com/g/validatedpatterns","install":"getting-started"},"other_products":["Veeam Kasten"],"pattern_logo":"veeam-kasten.png","publishdate":"2024-10-28T00:00:00Z","rh_products":["Red Hat OpenShift Container Platform","Red Hat Ansible Automation Platform","Red Hat OpenShift Virtualization","Red Hat Enterprise Linux","Red Hat OpenShift Data Foundation"],"summary":"This pattern uses OpenShift Virtualization to simulate an edge environment for VMs, protected by Veeam Kasten.","tier":"sandbox","title":"Ansible Edge GitOps with Veeam Kasten"}},{"Ansible GitOps Framework":{"aliases":["/agof/"],"date":"2024-06-13T00:00:00Z","draft":false,"industries":null,"iscjklanguage":false,"lastmod":"2024-06-13T00:00:00Z","links":{"bugs":"https://github.com/validatedpatterns/agof/issues","help":"https://groups.google.com/g/validatedpatterns","install":"https://github.com/validatedpatterns/agof/"},"pattern_logo":"ansible-edge.png","publishdate":"2024-06-13T00:00:00Z","rh_products":["Red Hat Ansible Automation Platform","Red Hat Enterprise Linux"],"summary":"This variant of the Validated Patterns framework exists to support GitOps outside of Kubernetes.","tier":"sandbox","title":"Ansible GitOps Framework"}},{"Cockroach":{"draft":false,"iscjklanguage":false,"rh_products":["Red Hat OpenShift Container Platform","Red Hat Advanced Cluster Management"],"summary":"A multicloud pattern using cockroachdb and submariner, deployed via RHACM.","tier":"sandbox","title":"Cockroach"}},{"Confidential Containers pattern":{"aliases":["/coco-pattern/"],"date":"2024-10-03T00:00:00Z","draft":false,"industries":["General"],"iscjklanguage":false,"lastmod":"2024-10-03T00:00:00Z","links":{"bugs":"https://github.com/validatedpatterns/coco-pattern/issues","help":"https://groups.google.com/g/validatedpatterns","install":"coco-getting-started"},"pattern_logo":"coco-logo.png","publishdate":"2024-10-03T00:00:00Z","rh_products":["Red Hat OpenShift Container Platform","Red Hat Advanced Cluster Management","Red Hat OpenShift Sandbox Containers"],"summary":"This pattern helps you get started with deploying confidential containers in OpenShift Container Platform.","tier":"sandbox","title":"Confidential Containers pattern"}},{"Connected Vehicle Architecture":{"draft":false,"iscjklanguage":false,"rh_products":["Red Hat OpenShift Container Platform","Red Hat Ansible Automation Platform"],"summary":"A distributed cloud-native application that implements key aspects of a modern IoT architecture.","tier":"sandbox","title":"Connected Vehicle Architecture"}},{"Emerging Disease Detection":{"// pattern_logo":"emerging-disease-detection.png","aliases":["/emerging-disease-detection/"],"ci":"edd","contributor":{"contact":"mailto:anattama@redhat.com","git":"https://github.com/arunhari82","name":"Arunkumar Nattamai Hariharan"},"date":"2023-09-23T00:00:00Z","draft":false,"industries":["medical"],"iscjklanguage":false,"lastmod":"2023-09-23T00:00:00Z","links":{"arch":"https://www.redhat.com/architect/portfolio/detail/6-enabling-medical-imaging-diagnostics-with-edge","bugs":"https://github.com/validatedpatterns/emerging-disease-detection/issues","help":"https://groups.google.com/g/validatedpatterns","install":"edd-getting-started"},"publishdate":"2023-09-23T00:00:00Z","rh_products":["Red Hat OpenShift Container Platform","Red Hat OpenShift Serverless","Red Hat Single Sign-On","Red Hat AMQ Streams"],"summary":"This pattern is based on a demo implementation of an automated data pipeline for sepsis analysis previously developed by Red Hat.","tier":"sandbox","title":"Emerging Disease Detection"}},{"HyperShift":{"aliases":["/hypershift/"],"ci":"hypershift","date":"2023-11-15T00:00:00Z","draft":false,"industries":["Infrastructure"],"iscjklanguage":false,"lastmod":"2023-11-15T00:00:00Z","links":{"bugs":"https://github.com/validatedpatterns-sandbox/hypershift/issues","help":"https://groups.google.com/g/validatedpatterns"},"other_products":["AWS Controller for Kubernetes"],"pattern_logo":"medical-diagnosis.png","publishdate":"2023-11-15T00:00:00Z","rh_products":["Red Hat OpenShift Container Platform","Red Hat MultiCluster Engine"],"summary":"This pattern is for deploying the Hosted Control Plane (HyperShift) service.","tier":"sandbox","title":"HyperShift"}},{"Industrial Edge":{"aliases":["/industrial-edge/"],"ci":"manuela","date":"2021-10-12T00:00:00Z","draft":false,"industries":["Industrial","Manufacturing"],"iscjklanguage":false,"lastmod":"2021-10-12T00:00:00Z","links":{"arch":"https://www.redhat.com/architect/portfolio/detail/26-industrial-edge","bugs":"https://github.com/validatedpatterns/industrial-edge/issues","help":"https://groups.google.com/g/validatedpatterns","install":"getting-started"},"pattern_logo":"industrial-edge.png","publishdate":"2021-10-12T00:00:00Z","rh_products":["Red Hat OpenShift Container Platform","Red Hat Advanced Cluster Management","Red Hat Quay","Red Hat AMQ"],"summary":"This pattern demonstrates a horizontal solution for Industrial Edge use cases.","tier":"maintained","title":"Industrial Edge"}},{"Intel AMX accelerated Medical Diagnosis":{"aliases":["/medical-diagnosis-amx/"],"date":"2023-10-10T00:00:00Z","draft":false,"industries":["medical"],"iscjklanguage":false,"lastmod":"2023-10-10T00:00:00Z","links":{"arch":"https://www.redhat.com/architect/portfolio/detail/6-enabling-medical-imaging-diagnostics-with-edge","bugs":"https://github.com/validatedpatterns-sandbox/amx-accelerated-medical-diagnosis/issues","help":"https://groups.google.com/g/hybrid-cloud-patterns","install":"getting-started"},"pattern_logo":"medical-diagnosis.png","products":["Red Hat OpenShift Container Platform","Red Hat OpenShift Serverless","Red Hat OpenShift Data Foundation","Red Hat OpenShift Node Feature Discovery","4th Gen Intel Xeon Scalable processors with Intel Advanced Matrix Extensions (Intel AMX)"],"publishdate":"2023-10-10T00:00:00Z","summary":"This pattern is based on a demo implementation of an automated data pipeline for chest X-ray analysis previously developed by Red Hat. The pattern is modified to utilize Intel AMX feature.","title":"Intel AMX accelerated Medical Diagnosis","validated":false}},{"Intel AMX accelerated Multicloud GitOps":{"aliases":["/multicloud-gitops-amx/"],"date":"2023-10-05T00:00:00Z","draft":false,"industries":["General"],"iscjklanguage":false,"lastmod":"2023-10-05T00:00:00Z","links":{"bugs":"https://github.com/validatedpatterns-sandbox/amx-accelerated-multicloud-gitops/issues","help":"https://groups.google.com/g/hybrid-cloud-patterns","install":"mcg-amx-getting-started"},"pattern_logo":"amx-intel-ai.png","products":["Red Hat OpenShift Container Platform","Red Hat Advanced Cluster Management","Red Hat Node Feature Discovery","4th Gen Intel Xeon Scalable processors with Intel Advanced Matrix Extensions (Intel AMX)"],"publishdate":"2023-10-05T00:00:00Z","summary":"This is extension of Multicloud GitOps pattern with additional application to show the value of using Intel AMX.","title":"Intel AMX accelerated Multicloud GitOps","validated":false}},{"Intel AMX accelerated Multicloud GitOps with Openshift AI":{"aliases":["/multicloud-gitops-amx-rhoai/"],"date":"2024-02-27T00:00:00Z","draft":false,"industries":["General"],"iscjklanguage":false,"lastmod":"2024-02-27T00:00:00Z","links":{"bugs":"https://github.com/validatedpatterns-sandbox/amx-accelerated-multicloud-gitops/issues","help":"https://groups.google.com/g/hybrid-cloud-patterns","install":"mcg-amx-rhoai-getting-started"},"pattern_logo":"amx-intel-ai.png","products":["Red Hat OpenShift Container Platform","Red Hat Advanced Cluster Management","Red Hat Openshift AI","OpenVINO Toolkit Operator","5th Gen Intel Xeon Scalable processors with Intel Advanced Matrix Extensions (Intel AMX)"],"publishdate":"2024-02-27T00:00:00Z","summary":"This is extension of Multicloud GitOps pattern with Red Hat Openshift AI component to show the value of using Intel AMX.","title":"Intel AMX accelerated Multicloud GitOps with Openshift AI","validated":false}},{"Intel QAT accelerated Multicloud GitOps":{"aliases":["/multicloud-gitops-qat/"],"date":"2023-10-05T00:00:00Z","draft":false,"industries":["General"],"iscjklanguage":false,"lastmod":"2023-10-05T00:00:00Z","links":{"bugs":"https://github.com/validatedpatterns-sandbox/qat-accelerated-istio/issues","help":"https://groups.google.com/g/hybrid-cloud-patterns","install":"mcg-qat-getting-started"},"pattern_logo":"intel-qat.png","products":["Red Hat OpenShift Container Platform","Red Hat Advanced Cluster Management","Red Hat Node Feature Discovery","4th Gen Intel Xeon Scalable processors with Intel QuickAssist Technology (Intel QAT)","Sail Operator (Istio Service Mesh)","Intel Device Plugin Operator"],"publishdate":"2023-10-05T00:00:00Z","summary":"This is extension of Multicloud GitOps pattern with additional application to show the value of using Intel QAT.","title":"Intel QAT accelerated Multicloud GitOps","validated":false}},{"Intel SGX protected application in Multicloud GitOps":{"aliases":["/multicloud-gitops-sgx-hello-world/"],"date":"2024-02-20T00:00:00Z","draft":false,"industries":["General"],"iscjklanguage":false,"lastmod":"2024-02-20T00:00:00Z","links":{"help":"https://groups.google.com/g/hybrid-cloud-patterns","install":"mcg-sgx-hello-world-getting-started"},"pattern_logo":"sgx-intel-ai.png","products":["Red Hat OpenShift Container Platform","Red Hat Advanced Cluster Management","Red Hat Node Feature Discovery","Intel Device Plugins Operator","5th Gen Intel Xeon Scalable processors with Intel Software Guard Extensions (Intel SGX)"],"publishdate":"2024-02-20T00:00:00Z","summary":"This is an extension of Multicloud GitOps pattern with additional application using Intel SGX.","title":"Intel SGX protected application in Multicloud GitOps","validated":false}},{"Intel SGX protected Vault for Multicloud GitOps":{"aliases":["/multicloud-gitops-sgx/"],"date":"2024-02-09T00:00:00Z","draft":false,"industries":["General"],"iscjklanguage":false,"lastmod":"2024-02-09T00:00:00Z","links":{"bugs":"https://github.com/validatedpatterns-sandbox/sgx-multicloud-gitops-vault/issues","help":"https://groups.google.com/g/hybrid-cloud-patterns","install":"mcg-sgx-getting-started"},"pattern_logo":"sgx-intel-ai.png","products":["Red Hat OpenShift Container Platform","Red Hat Advanced Cluster Management","Red Hat Node Feature Discovery","Intel Device Plugins","5th Gen Intel Xeon Scalable processors with Intel Security Guard Extensions (Intel SGX)"],"publishdate":"2024-02-09T00:00:00Z","summary":"This is an extension of the Multicloud GitOps pattern with an additional application to show the value of using Intel SGX.","title":"Intel SGX protected Vault for Multicloud GitOps","validated":false}},{"Kong":{"draft":false,"iscjklanguage":false,"rh_products":["Red Hat OpenShift Container Platform"],"summary":"A pattern for Kong Gateway Control Plane and Data Plane demo.","tier":"sandbox","title":"Kong"}},{"Medical Diagnosis":{"aliases":["/medical-diagnosis/"],"ci":"medicaldiag","date":"2021-01-19T00:00:00Z","draft":false,"industries":["medical"],"iscjklanguage":false,"lastmod":"2021-01-19T00:00:00Z","links":{"arch":"https://www.redhat.com/architect/portfolio/detail/6-enabling-medical-imaging-diagnostics-with-edge","bugs":"https://github.com/validatedpatterns/medical-diagnosis/issues","help":"https://groups.google.com/g/validatedpatterns","install":"getting-started"},"pattern_logo":"medical-diagnosis.png","publishdate":"2021-01-19T00:00:00Z","rh_products":["Red Hat OpenShift Container Platform","Red Hat OpenShift Serverless","Red Hat OpenShift Data Foundation"],"summary":"This pattern is based on a demo implementation of an automated data pipeline for chest X-ray analysis previously developed by Red Hat.","tier":"maintained","title":"Medical Diagnosis"}},{"MLOps Fraud Detection":{"aliases":["/mlops-fraud-detection/"],"ci":"mfd","contributor":{"contact":"mailto:arskhan@redhat.com","git":"https://github.com/arslankhanali","name":"Arslan Khan"},"date":"2023-11-12T00:00:00Z","draft":false,"industries":["financial services"],"iscjklanguage":false,"lastmod":"2023-11-12T00:00:00Z","links":{"arch":"https://www.redhat.com/architect/portfolio/architecturedetail?ppid=6","bugs":"https://github.com/validatedpatterns/mlops-fraud-detection/issues","help":"https://groups.google.com/g/validatedpatterns","install":"mfd-getting-started"},"pattern_logo":"mlops-fraud-detection.png","publishdate":"2023-11-12T00:00:00Z","rh_products":["Red Hat OpenShift Container Platform","Red Hat OpenShift Data Science","Red Hat OpenShift Data Foundation"],"summary":"This pattern demonstrates how Red Hat OpenShift Data Science and MLFlow can be used together to build an end-to-end MLOps platform. It demonstrates this using a credit card fraud detection use case.","tier":"sandbox","title":"MLOps Fraud Detection"}},{"Multicloud GitOps":{"aliases":["/multicloud-gitops/"],"ci":"mcgitops","date":"2021-12-11T00:00:00Z","draft":false,"industries":["General"],"iscjklanguage":false,"lastmod":"2021-12-11T00:00:00Z","links":{"arch":"https://www.redhat.com/architect/portfolio/detail/8-hybrid-multicloud-management-with-gitops","bugs":"https://github.com/validatedpatterns/multicloud-gitops/issues","help":"https://groups.google.com/g/validatedpatterns","install":"mcg-getting-started"},"pattern_logo":"multicloud-gitops.png","publishdate":"2021-12-11T00:00:00Z","rh_products":["Red Hat OpenShift Container Platform","Red Hat Advanced Cluster Management"],"summary":"This pattern helps you develop and deploy applications on an open hybrid cloud in a stable, simple, and secure way.","tier":"maintained","title":"Multicloud GitOps"}},{"Multicloud GitOps with Portworx Enterprise":{"aliases":["/multicloud-gitops-Portworx/"],"date":"2023-18-05","draft":false,"industries":["General"],"iscjklanguage":false,"links":{"bugs":"https://github.com/portworx/rh-multicloud-gitops-pxe/issues","help":"https://groups.google.com/g/validatedpatterns","install":"getting-started"},"other_products":["Portworx Enterprise"],"pattern_logo":"multicloud-gitops-Portworx.png","rh_products":["Red Hat OpenShift Container Platform","Red Hat Advanced Cluster Management"],"summary":"This pattern helps you develop and deploy applications on an open hybrid cloud in a stable, simple, and secure way. It includes persistent storage for stateful applications.","tier":"sandbox","title":"Multicloud GitOps with Portworx Enterprise"}},{"Multicluster DevSecOps":{"aliases":["/devsecops/"],"ci":"devsecops","date":"2022-06-08T00:00:00Z","draft":false,"industries":["General"],"iscjklanguage":false,"lastmod":"2022-06-08T00:00:00Z","links":{"bugs":"https://github.com/validatedpatterns/multicluster-devsecops/issues","help":"https://groups.google.com/g/validatedpatterns","install":"getting-started"},"publishdate":"2022-06-08T00:00:00Z","rh_products":["Red Hat OpenShift Container Platform","Red Hat Advanced Cluster Management","Red Hat Quay","Red Hat OpenShift Data Foundation","Red Hat Advanced Cluster Security"],"summary":"This pattern is derived from the multi-cloud GitOps pattern with added products to provide a complete DevSecOps workflow.","tier":"sandbox","title":"Multicluster DevSecOps"}},{"OPEA QnA chat accelerated with Intel Gaudi":{"aliases":["/gaudi-rag-chat-qna/"],"date":"2024-06-01T00:00:00Z","draft":false,"industries":["General"],"iscjklanguage":false,"lastmod":"2024-06-01T00:00:00Z","links":{"bugs":"https://github.com/validatedpatterns-sandbox/","help":"https://groups.google.com/g/hybrid-cloud-patterns","install":"gaudi-rag-chat-qna-getting-started"},"publishdate":"2024-06-01T00:00:00Z","rh_products":["Red Hat OpenShift Container Platform","Red Hat OpenShift Data Foundation","Red Hat OpenShift AI","Red Hat OpenShift Serverless","Red Hat OpenShift Service Mesh"],"summary":"This pattern helps you deploy stack enabling Intel Gaudi Accelerator and it also deploys RAG application - Chat QnA","title":"OPEA QnA chat accelerated with Intel Gaudi","validated":false}},{"OpenShift AI":{"aliases":["/rhoai/"],"ci":"rhoai","date":"2024-04-22T00:00:00Z","draft":false,"industries":["General"],"iscjklanguage":false,"lastmod":"2024-04-22T00:00:00Z","links":{"bugs":"https://github.com/validatedpatterns-sandbox/travelops/issues","help":"https://groups.google.com/g/validatedpatterns","install":"getting-started"},"publishdate":"2024-04-22T00:00:00Z","rh_products":["Red Hat OpenShift Container Platform","Red Hat OpenShift AI","Red Hat Pipelines"],"summary":"This pattern is a starting point for using Red Hat OpenShift AI.","tier":"sandbox","title":"OpenShift AI"}},{"Regional Disaster Recovery":{"date":"2024-09-20T00:00:00Z","draft":false,"industries":null,"iscjklanguage":false,"lastmod":"2024-09-20T00:00:00Z","links":{"bugs":"https://github.com/validatedpatterns/regional-resiliency-pattern/issues","help":"https://groups.google.com/g/validatedpatterns","install":"https://github.com/validatedpatterns/regional-resiliency-pattern"},"pattern_logo":"regional-dr.png","publishdate":"2024-09-20T00:00:00Z","rh_products":["Red Hat OpenShift Container Platform"],"summary":"This variant of the Validated Patterns framework deploys a Regional Disaster Recovery Setup across multiple different regions","tier":"sandbox","title":"Regional Disaster Recovery"}},{"Retail":{"aliases":["/retail/"],"ci":"retail","date":"2022-12-08T00:00:00Z","draft":false,"industries":["Retail"],"iscjklanguage":false,"lastmod":"2022-12-08T00:00:00Z","links":{"bugs":"https://github.com/validatedpatterns/retail/issues","help":"https://groups.google.com/g/validatedpatterns","install":"getting-started"},"publishdate":"2022-12-08T00:00:00Z","rh_products":["Red Hat OpenShift Container Platform","Red Hat Advanced Cluster Management","Red Hat AMQ"],"summary":"This pattern demonstrates a pattern that models the store side of a retail application.","tier":"tested","title":"Retail"}},{"TravelOps":{"aliases":["/travelops/"],"ci":"travelops","date":"2024-02-09T00:00:00Z","draft":false,"industries":["General"],"iscjklanguage":false,"lastmod":"2024-02-09T00:00:00Z","links":{"bugs":"https://github.com/validatedpatterns-sandbox/travelops/issues","help":"https://groups.google.com/g/validatedpatterns","install":"getting-started"},"publishdate":"2024-02-09T00:00:00Z","rh_products":["Red Hat OpenShift Container Platform","Red Hat Service Mesh","Red Hat Kiali","Red Hat Jaeger Distributed Tracing","Red Hat ElasticSearch"],"summary":"This pattern enables you to secure your applications using Red Hat Service Mesh.","tier":"tested","title":"TravelOps"}}]
\ No newline at end of file
diff --git a/patterns/industrial-edge/application/index.html b/patterns/industrial-edge/application/index.html
index 2dbd387e8..023f08782 100644
--- a/patterns/industrial-edge/application/index.html
+++ b/patterns/industrial-edge/application/index.html
@@ -3747,7 +3747,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/industrial-edge/cluster-sizing/index.html b/patterns/industrial-edge/cluster-sizing/index.html
index 891ad795c..bed915850 100644
--- a/patterns/industrial-edge/cluster-sizing/index.html
+++ b/patterns/industrial-edge/cluster-sizing/index.html
@@ -3740,7 +3740,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/industrial-edge/demo-script/index.html b/patterns/industrial-edge/demo-script/index.html
index 8c909630c..1f6cb32e0 100644
--- a/patterns/industrial-edge/demo-script/index.html
+++ b/patterns/industrial-edge/demo-script/index.html
@@ -3739,7 +3739,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/industrial-edge/factory/index.html b/patterns/industrial-edge/factory/index.html
index b7f68eaf6..62d218ef1 100644
--- a/patterns/industrial-edge/factory/index.html
+++ b/patterns/industrial-edge/factory/index.html
@@ -3753,7 +3753,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/industrial-edge/getting-started/index.html b/patterns/industrial-edge/getting-started/index.html
index a107e2140..2b8299b06 100644
--- a/patterns/industrial-edge/getting-started/index.html
+++ b/patterns/industrial-edge/getting-started/index.html
@@ -3846,7 +3846,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/industrial-edge/ideas-for-customization/index.html b/patterns/industrial-edge/ideas-for-customization/index.html
index 4deb97788..ba5d09195 100644
--- a/patterns/industrial-edge/ideas-for-customization/index.html
+++ b/patterns/industrial-edge/ideas-for-customization/index.html
@@ -3739,7 +3739,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/industrial-edge/index.html b/patterns/industrial-edge/index.html
index 3e9e743ee..8bcb50be4 100644
--- a/patterns/industrial-edge/index.html
+++ b/patterns/industrial-edge/index.html
@@ -3746,7 +3746,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/industrial-edge/troubleshooting/index.html b/patterns/industrial-edge/troubleshooting/index.html
index df76a1f82..79dd0812f 100644
--- a/patterns/industrial-edge/troubleshooting/index.html
+++ b/patterns/industrial-edge/troubleshooting/index.html
@@ -3759,7 +3759,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/kong-gateway/index.html b/patterns/kong-gateway/index.html
index ac34cc80b..ae62b04b3 100644
--- a/patterns/kong-gateway/index.html
+++ b/patterns/kong-gateway/index.html
@@ -3739,7 +3739,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/medical-diagnosis-amx/cluster-sizing/index.html b/patterns/medical-diagnosis-amx/cluster-sizing/index.html
index 03274c41a..83fc1b45c 100644
--- a/patterns/medical-diagnosis-amx/cluster-sizing/index.html
+++ b/patterns/medical-diagnosis-amx/cluster-sizing/index.html
@@ -3738,7 +3738,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/medical-diagnosis-amx/getting-started/index.html b/patterns/medical-diagnosis-amx/getting-started/index.html
index ee57ade60..33e2564e6 100644
--- a/patterns/medical-diagnosis-amx/getting-started/index.html
+++ b/patterns/medical-diagnosis-amx/getting-started/index.html
@@ -3819,7 +3819,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/medical-diagnosis-amx/ideas-for-customization/index.html b/patterns/medical-diagnosis-amx/ideas-for-customization/index.html
index 87edfba01..35cf6dafe 100644
--- a/patterns/medical-diagnosis-amx/ideas-for-customization/index.html
+++ b/patterns/medical-diagnosis-amx/ideas-for-customization/index.html
@@ -3739,7 +3739,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/medical-diagnosis-amx/index.html b/patterns/medical-diagnosis-amx/index.html
index 1ba69bab0..2bf029e09 100644
--- a/patterns/medical-diagnosis-amx/index.html
+++ b/patterns/medical-diagnosis-amx/index.html
@@ -3745,7 +3745,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/medical-diagnosis-amx/troubleshooting/index.html b/patterns/medical-diagnosis-amx/troubleshooting/index.html
index c0c2f4ce7..64ff78d67 100644
--- a/patterns/medical-diagnosis-amx/troubleshooting/index.html
+++ b/patterns/medical-diagnosis-amx/troubleshooting/index.html
@@ -3770,7 +3770,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/medical-diagnosis/cluster-sizing/index.html b/patterns/medical-diagnosis/cluster-sizing/index.html
index 40c9ccd0f..4b0541628 100644
--- a/patterns/medical-diagnosis/cluster-sizing/index.html
+++ b/patterns/medical-diagnosis/cluster-sizing/index.html
@@ -3738,7 +3738,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/medical-diagnosis/demo-script/index.html b/patterns/medical-diagnosis/demo-script/index.html
index 880e6b635..8e9fd5ed9 100644
--- a/patterns/medical-diagnosis/demo-script/index.html
+++ b/patterns/medical-diagnosis/demo-script/index.html
@@ -3748,7 +3748,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/medical-diagnosis/getting-started/index.html b/patterns/medical-diagnosis/getting-started/index.html
index 02451f1d1..01b9340dd 100644
--- a/patterns/medical-diagnosis/getting-started/index.html
+++ b/patterns/medical-diagnosis/getting-started/index.html
@@ -3812,7 +3812,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/medical-diagnosis/ideas-for-customization/index.html b/patterns/medical-diagnosis/ideas-for-customization/index.html
index 7ed41ed4c..0ad60f413 100644
--- a/patterns/medical-diagnosis/ideas-for-customization/index.html
+++ b/patterns/medical-diagnosis/ideas-for-customization/index.html
@@ -3739,7 +3739,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/medical-diagnosis/index.html b/patterns/medical-diagnosis/index.html
index d98f7f783..efb353397 100644
--- a/patterns/medical-diagnosis/index.html
+++ b/patterns/medical-diagnosis/index.html
@@ -3743,7 +3743,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/medical-diagnosis/troubleshooting/index.html b/patterns/medical-diagnosis/troubleshooting/index.html
index ce0f9fcb3..cc8d58506 100644
--- a/patterns/medical-diagnosis/troubleshooting/index.html
+++ b/patterns/medical-diagnosis/troubleshooting/index.html
@@ -3770,7 +3770,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/mlops-fraud-detection/index.html b/patterns/mlops-fraud-detection/index.html
index 914d3cc1b..8416259b7 100644
--- a/patterns/mlops-fraud-detection/index.html
+++ b/patterns/mlops-fraud-detection/index.html
@@ -3743,7 +3743,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/mlops-fraud-detection/mfd-getting-started/index.html b/patterns/mlops-fraud-detection/mfd-getting-started/index.html
index 99a976d33..97ca83645 100644
--- a/patterns/mlops-fraud-detection/mfd-getting-started/index.html
+++ b/patterns/mlops-fraud-detection/mfd-getting-started/index.html
@@ -3772,7 +3772,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/mlops-fraud-detection/mfd-running-the-demo/index.html b/patterns/mlops-fraud-detection/mfd-running-the-demo/index.html
index 6016a224c..7b83a3c23 100644
--- a/patterns/mlops-fraud-detection/mfd-running-the-demo/index.html
+++ b/patterns/mlops-fraud-detection/mfd-running-the-demo/index.html
@@ -3819,7 +3819,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/multicloud-gitops-amx-rhoai/index.html b/patterns/multicloud-gitops-amx-rhoai/index.html
index 7ae62b83e..4d5992643 100644
--- a/patterns/multicloud-gitops-amx-rhoai/index.html
+++ b/patterns/multicloud-gitops-amx-rhoai/index.html
@@ -3745,7 +3745,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/multicloud-gitops-amx-rhoai/mcg-amx-rhoai-bert-script/index.html b/patterns/multicloud-gitops-amx-rhoai/mcg-amx-rhoai-bert-script/index.html
index 7321c436f..a2163e8bc 100644
--- a/patterns/multicloud-gitops-amx-rhoai/mcg-amx-rhoai-bert-script/index.html
+++ b/patterns/multicloud-gitops-amx-rhoai/mcg-amx-rhoai-bert-script/index.html
@@ -3740,7 +3740,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/multicloud-gitops-amx-rhoai/mcg-amx-rhoai-cluster-sizing/index.html b/patterns/multicloud-gitops-amx-rhoai/mcg-amx-rhoai-cluster-sizing/index.html
index 9a7df3720..6664372e4 100644
--- a/patterns/multicloud-gitops-amx-rhoai/mcg-amx-rhoai-cluster-sizing/index.html
+++ b/patterns/multicloud-gitops-amx-rhoai/mcg-amx-rhoai-cluster-sizing/index.html
@@ -3738,7 +3738,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/multicloud-gitops-amx-rhoai/mcg-amx-rhoai-demo-script/index.html b/patterns/multicloud-gitops-amx-rhoai/mcg-amx-rhoai-demo-script/index.html
index 3f61e9527..73beea7e5 100644
--- a/patterns/multicloud-gitops-amx-rhoai/mcg-amx-rhoai-demo-script/index.html
+++ b/patterns/multicloud-gitops-amx-rhoai/mcg-amx-rhoai-demo-script/index.html
@@ -3759,7 +3759,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/multicloud-gitops-amx-rhoai/mcg-amx-rhoai-getting-started/index.html b/patterns/multicloud-gitops-amx-rhoai/mcg-amx-rhoai-getting-started/index.html
index 108409e9e..5123d2d13 100644
--- a/patterns/multicloud-gitops-amx-rhoai/mcg-amx-rhoai-getting-started/index.html
+++ b/patterns/multicloud-gitops-amx-rhoai/mcg-amx-rhoai-getting-started/index.html
@@ -3739,7 +3739,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/multicloud-gitops-amx-rhoai/mcg-amx-rhoai-ideas-for-customization/index.html b/patterns/multicloud-gitops-amx-rhoai/mcg-amx-rhoai-ideas-for-customization/index.html
index 93b32a1fe..23b484630 100644
--- a/patterns/multicloud-gitops-amx-rhoai/mcg-amx-rhoai-ideas-for-customization/index.html
+++ b/patterns/multicloud-gitops-amx-rhoai/mcg-amx-rhoai-ideas-for-customization/index.html
@@ -3738,7 +3738,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/multicloud-gitops-amx-rhoai/mcg-amx-rhoai-imperative-actions/index.html b/patterns/multicloud-gitops-amx-rhoai/mcg-amx-rhoai-imperative-actions/index.html
index a054472b5..50a887461 100644
--- a/patterns/multicloud-gitops-amx-rhoai/mcg-amx-rhoai-imperative-actions/index.html
+++ b/patterns/multicloud-gitops-amx-rhoai/mcg-amx-rhoai-imperative-actions/index.html
@@ -3777,7 +3777,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/multicloud-gitops-amx-rhoai/mcg-amx-rhoai-managed-cluster/index.html b/patterns/multicloud-gitops-amx-rhoai/mcg-amx-rhoai-managed-cluster/index.html
index 0ce0f4fad..6d7a28443 100644
--- a/patterns/multicloud-gitops-amx-rhoai/mcg-amx-rhoai-managed-cluster/index.html
+++ b/patterns/multicloud-gitops-amx-rhoai/mcg-amx-rhoai-managed-cluster/index.html
@@ -3766,7 +3766,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/multicloud-gitops-amx/index.html b/patterns/multicloud-gitops-amx/index.html
index 4aa030eed..8b76e323c 100644
--- a/patterns/multicloud-gitops-amx/index.html
+++ b/patterns/multicloud-gitops-amx/index.html
@@ -3745,7 +3745,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/multicloud-gitops-amx/mcg-amx-cluster-sizing/index.html b/patterns/multicloud-gitops-amx/mcg-amx-cluster-sizing/index.html
index 59794a53a..a162741ea 100644
--- a/patterns/multicloud-gitops-amx/mcg-amx-cluster-sizing/index.html
+++ b/patterns/multicloud-gitops-amx/mcg-amx-cluster-sizing/index.html
@@ -3738,7 +3738,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/multicloud-gitops-amx/mcg-amx-getting-started/index.html b/patterns/multicloud-gitops-amx/mcg-amx-getting-started/index.html
index 0049db196..d4b1caf04 100644
--- a/patterns/multicloud-gitops-amx/mcg-amx-getting-started/index.html
+++ b/patterns/multicloud-gitops-amx/mcg-amx-getting-started/index.html
@@ -3739,7 +3739,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/multicloud-gitops-amx/mcg-amx-ideas-for-customization/index.html b/patterns/multicloud-gitops-amx/mcg-amx-ideas-for-customization/index.html
index 08a52536d..0790d8b6f 100644
--- a/patterns/multicloud-gitops-amx/mcg-amx-ideas-for-customization/index.html
+++ b/patterns/multicloud-gitops-amx/mcg-amx-ideas-for-customization/index.html
@@ -3738,7 +3738,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/multicloud-gitops-amx/mcg-amx-imperative-actions/index.html b/patterns/multicloud-gitops-amx/mcg-amx-imperative-actions/index.html
index 8bf5d05cc..65c2a3474 100644
--- a/patterns/multicloud-gitops-amx/mcg-amx-imperative-actions/index.html
+++ b/patterns/multicloud-gitops-amx/mcg-amx-imperative-actions/index.html
@@ -3777,7 +3777,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/multicloud-gitops-amx/mcg-amx-managed-cluster/index.html b/patterns/multicloud-gitops-amx/mcg-amx-managed-cluster/index.html
index 765f29ffe..89954fc47 100644
--- a/patterns/multicloud-gitops-amx/mcg-amx-managed-cluster/index.html
+++ b/patterns/multicloud-gitops-amx/mcg-amx-managed-cluster/index.html
@@ -3766,7 +3766,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/multicloud-gitops-portworx/cluster-sizing/index.html b/patterns/multicloud-gitops-portworx/cluster-sizing/index.html
index ffb81896c..8051c08b1 100644
--- a/patterns/multicloud-gitops-portworx/cluster-sizing/index.html
+++ b/patterns/multicloud-gitops-portworx/cluster-sizing/index.html
@@ -3740,7 +3740,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/multicloud-gitops-portworx/getting-started/index.html b/patterns/multicloud-gitops-portworx/getting-started/index.html
index e51f4b3dd..21630978a 100644
--- a/patterns/multicloud-gitops-portworx/getting-started/index.html
+++ b/patterns/multicloud-gitops-portworx/getting-started/index.html
@@ -3759,7 +3759,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/multicloud-gitops-portworx/ideas-for-customization/index.html b/patterns/multicloud-gitops-portworx/ideas-for-customization/index.html
index 0c6772ff1..9f662a03d 100644
--- a/patterns/multicloud-gitops-portworx/ideas-for-customization/index.html
+++ b/patterns/multicloud-gitops-portworx/ideas-for-customization/index.html
@@ -3740,7 +3740,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/multicloud-gitops-portworx/index.html b/patterns/multicloud-gitops-portworx/index.html
index 0053a168b..378e8b6ed 100644
--- a/patterns/multicloud-gitops-portworx/index.html
+++ b/patterns/multicloud-gitops-portworx/index.html
@@ -3744,7 +3744,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/multicloud-gitops-portworx/managed-cluster/index.html b/patterns/multicloud-gitops-portworx/managed-cluster/index.html
index 62b40cb69..7d54f157e 100644
--- a/patterns/multicloud-gitops-portworx/managed-cluster/index.html
+++ b/patterns/multicloud-gitops-portworx/managed-cluster/index.html
@@ -3774,7 +3774,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/multicloud-gitops-qat/index.html b/patterns/multicloud-gitops-qat/index.html
index 40ce5f15b..0d67120fb 100644
--- a/patterns/multicloud-gitops-qat/index.html
+++ b/patterns/multicloud-gitops-qat/index.html
@@ -3744,7 +3744,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/multicloud-gitops-qat/mcg-qat-cluster-sizing/index.html b/patterns/multicloud-gitops-qat/mcg-qat-cluster-sizing/index.html
index 4ff8d598c..1ff1a25f8 100644
--- a/patterns/multicloud-gitops-qat/mcg-qat-cluster-sizing/index.html
+++ b/patterns/multicloud-gitops-qat/mcg-qat-cluster-sizing/index.html
@@ -3738,7 +3738,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/multicloud-gitops-qat/mcg-qat-getting-started/index.html b/patterns/multicloud-gitops-qat/mcg-qat-getting-started/index.html
index 99a343db8..df551bbf4 100644
--- a/patterns/multicloud-gitops-qat/mcg-qat-getting-started/index.html
+++ b/patterns/multicloud-gitops-qat/mcg-qat-getting-started/index.html
@@ -3758,7 +3758,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/multicloud-gitops-qat/mcg-qat-ideas-for-customization/index.html b/patterns/multicloud-gitops-qat/mcg-qat-ideas-for-customization/index.html
index a1e9d07a2..a9c0efb1e 100644
--- a/patterns/multicloud-gitops-qat/mcg-qat-ideas-for-customization/index.html
+++ b/patterns/multicloud-gitops-qat/mcg-qat-ideas-for-customization/index.html
@@ -3738,7 +3738,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/multicloud-gitops-qat/mcg-qat-imperative-actions/index.html b/patterns/multicloud-gitops-qat/mcg-qat-imperative-actions/index.html
index 0d8b2b1f3..c6977bb5d 100644
--- a/patterns/multicloud-gitops-qat/mcg-qat-imperative-actions/index.html
+++ b/patterns/multicloud-gitops-qat/mcg-qat-imperative-actions/index.html
@@ -3777,7 +3777,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/multicloud-gitops-qat/mcg-qat-managed-cluster/index.html b/patterns/multicloud-gitops-qat/mcg-qat-managed-cluster/index.html
index 7e90f6741..9cd0984a8 100644
--- a/patterns/multicloud-gitops-qat/mcg-qat-managed-cluster/index.html
+++ b/patterns/multicloud-gitops-qat/mcg-qat-managed-cluster/index.html
@@ -3766,7 +3766,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/multicloud-gitops-sgx-hello-world/index.html b/patterns/multicloud-gitops-sgx-hello-world/index.html
index 45aa04c95..08b31a2b2 100644
--- a/patterns/multicloud-gitops-sgx-hello-world/index.html
+++ b/patterns/multicloud-gitops-sgx-hello-world/index.html
@@ -3744,7 +3744,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/multicloud-gitops-sgx-hello-world/mcg-sgx-hello-world-cluster-sizing/index.html b/patterns/multicloud-gitops-sgx-hello-world/mcg-sgx-hello-world-cluster-sizing/index.html
index 3fd175478..faf20ff68 100644
--- a/patterns/multicloud-gitops-sgx-hello-world/mcg-sgx-hello-world-cluster-sizing/index.html
+++ b/patterns/multicloud-gitops-sgx-hello-world/mcg-sgx-hello-world-cluster-sizing/index.html
@@ -3738,7 +3738,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/multicloud-gitops-sgx-hello-world/mcg-sgx-hello-world-demo-script/index.html b/patterns/multicloud-gitops-sgx-hello-world/mcg-sgx-hello-world-demo-script/index.html
index 820072452..184d0a3ff 100644
--- a/patterns/multicloud-gitops-sgx-hello-world/mcg-sgx-hello-world-demo-script/index.html
+++ b/patterns/multicloud-gitops-sgx-hello-world/mcg-sgx-hello-world-demo-script/index.html
@@ -3759,7 +3759,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/multicloud-gitops-sgx-hello-world/mcg-sgx-hello-world-getting-started/index.html b/patterns/multicloud-gitops-sgx-hello-world/mcg-sgx-hello-world-getting-started/index.html
index 4c26977b3..a7e7e4c56 100644
--- a/patterns/multicloud-gitops-sgx-hello-world/mcg-sgx-hello-world-getting-started/index.html
+++ b/patterns/multicloud-gitops-sgx-hello-world/mcg-sgx-hello-world-getting-started/index.html
@@ -3745,7 +3745,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/multicloud-gitops-sgx-hello-world/mcg-sgx-hello-world-ideas-for-customization/index.html b/patterns/multicloud-gitops-sgx-hello-world/mcg-sgx-hello-world-ideas-for-customization/index.html
index 015e3f31a..1e80d0281 100644
--- a/patterns/multicloud-gitops-sgx-hello-world/mcg-sgx-hello-world-ideas-for-customization/index.html
+++ b/patterns/multicloud-gitops-sgx-hello-world/mcg-sgx-hello-world-ideas-for-customization/index.html
@@ -3738,7 +3738,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/multicloud-gitops-sgx-hello-world/mcg-sgx-hello-world-imperative-actions/index.html b/patterns/multicloud-gitops-sgx-hello-world/mcg-sgx-hello-world-imperative-actions/index.html
index 11c933db5..2affad7e7 100644
--- a/patterns/multicloud-gitops-sgx-hello-world/mcg-sgx-hello-world-imperative-actions/index.html
+++ b/patterns/multicloud-gitops-sgx-hello-world/mcg-sgx-hello-world-imperative-actions/index.html
@@ -3777,7 +3777,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/multicloud-gitops-sgx-hello-world/mcg-sgx-hello-world-managed-cluster/index.html b/patterns/multicloud-gitops-sgx-hello-world/mcg-sgx-hello-world-managed-cluster/index.html
index f3f392a32..1f5ddb7cf 100644
--- a/patterns/multicloud-gitops-sgx-hello-world/mcg-sgx-hello-world-managed-cluster/index.html
+++ b/patterns/multicloud-gitops-sgx-hello-world/mcg-sgx-hello-world-managed-cluster/index.html
@@ -3762,7 +3762,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/multicloud-gitops-sgx/index.html b/patterns/multicloud-gitops-sgx/index.html
index 3054c06af..dd3f08b3a 100644
--- a/patterns/multicloud-gitops-sgx/index.html
+++ b/patterns/multicloud-gitops-sgx/index.html
@@ -3774,7 +3774,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/multicloud-gitops-sgx/mcg-sgx-cluster-sizing/index.html b/patterns/multicloud-gitops-sgx/mcg-sgx-cluster-sizing/index.html
index e8a5a2511..c5dea59d8 100644
--- a/patterns/multicloud-gitops-sgx/mcg-sgx-cluster-sizing/index.html
+++ b/patterns/multicloud-gitops-sgx/mcg-sgx-cluster-sizing/index.html
@@ -3738,7 +3738,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/multicloud-gitops-sgx/mcg-sgx-demo-script/index.html b/patterns/multicloud-gitops-sgx/mcg-sgx-demo-script/index.html
index da9582355..61e7b2dc5 100644
--- a/patterns/multicloud-gitops-sgx/mcg-sgx-demo-script/index.html
+++ b/patterns/multicloud-gitops-sgx/mcg-sgx-demo-script/index.html
@@ -3759,7 +3759,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/multicloud-gitops-sgx/mcg-sgx-getting-started/index.html b/patterns/multicloud-gitops-sgx/mcg-sgx-getting-started/index.html
index c17da3b93..9b64c6b56 100644
--- a/patterns/multicloud-gitops-sgx/mcg-sgx-getting-started/index.html
+++ b/patterns/multicloud-gitops-sgx/mcg-sgx-getting-started/index.html
@@ -3830,7 +3830,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/multicloud-gitops-sgx/mcg-sgx-ideas-for-customization/index.html b/patterns/multicloud-gitops-sgx/mcg-sgx-ideas-for-customization/index.html
index 9ad96fc8e..0b5e6c8d6 100644
--- a/patterns/multicloud-gitops-sgx/mcg-sgx-ideas-for-customization/index.html
+++ b/patterns/multicloud-gitops-sgx/mcg-sgx-ideas-for-customization/index.html
@@ -3738,7 +3738,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/multicloud-gitops-sgx/mcg-sgx-imperative-actions/index.html b/patterns/multicloud-gitops-sgx/mcg-sgx-imperative-actions/index.html
index 566abf1ea..e7123e459 100644
--- a/patterns/multicloud-gitops-sgx/mcg-sgx-imperative-actions/index.html
+++ b/patterns/multicloud-gitops-sgx/mcg-sgx-imperative-actions/index.html
@@ -3777,7 +3777,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/multicloud-gitops-sgx/mcg-sgx-managed-cluster/index.html b/patterns/multicloud-gitops-sgx/mcg-sgx-managed-cluster/index.html
index 588b80ed6..234012bb4 100644
--- a/patterns/multicloud-gitops-sgx/mcg-sgx-managed-cluster/index.html
+++ b/patterns/multicloud-gitops-sgx/mcg-sgx-managed-cluster/index.html
@@ -3766,7 +3766,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/multicloud-gitops/index.html b/patterns/multicloud-gitops/index.html
index b822df4c6..17a1bc236 100644
--- a/patterns/multicloud-gitops/index.html
+++ b/patterns/multicloud-gitops/index.html
@@ -3744,7 +3744,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/multicloud-gitops/mcg-cluster-sizing/index.html b/patterns/multicloud-gitops/mcg-cluster-sizing/index.html
index 585cc30f8..e082b2a47 100644
--- a/patterns/multicloud-gitops/mcg-cluster-sizing/index.html
+++ b/patterns/multicloud-gitops/mcg-cluster-sizing/index.html
@@ -3738,7 +3738,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/multicloud-gitops/mcg-demo-script/index.html b/patterns/multicloud-gitops/mcg-demo-script/index.html
index b496c0826..89e8bfa9e 100644
--- a/patterns/multicloud-gitops/mcg-demo-script/index.html
+++ b/patterns/multicloud-gitops/mcg-demo-script/index.html
@@ -3759,7 +3759,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/multicloud-gitops/mcg-getting-started/index.html b/patterns/multicloud-gitops/mcg-getting-started/index.html
index ae4b1b9cd..7c9864073 100644
--- a/patterns/multicloud-gitops/mcg-getting-started/index.html
+++ b/patterns/multicloud-gitops/mcg-getting-started/index.html
@@ -3739,7 +3739,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/multicloud-gitops/mcg-ideas-for-customization/index.html b/patterns/multicloud-gitops/mcg-ideas-for-customization/index.html
index 605bfe0ca..8221042b2 100644
--- a/patterns/multicloud-gitops/mcg-ideas-for-customization/index.html
+++ b/patterns/multicloud-gitops/mcg-ideas-for-customization/index.html
@@ -3738,7 +3738,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/multicloud-gitops/mcg-imperative-actions/index.html b/patterns/multicloud-gitops/mcg-imperative-actions/index.html
index 1a62d1311..3644a4b07 100644
--- a/patterns/multicloud-gitops/mcg-imperative-actions/index.html
+++ b/patterns/multicloud-gitops/mcg-imperative-actions/index.html
@@ -3777,7 +3777,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/multicloud-gitops/mcg-managed-cluster/index.html b/patterns/multicloud-gitops/mcg-managed-cluster/index.html
index 8578ca48b..e1db81a29 100644
--- a/patterns/multicloud-gitops/mcg-managed-cluster/index.html
+++ b/patterns/multicloud-gitops/mcg-managed-cluster/index.html
@@ -3766,7 +3766,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/openshift-ai/getting-started/index.html b/patterns/openshift-ai/getting-started/index.html
index 638c81866..346a55e47 100644
--- a/patterns/openshift-ai/getting-started/index.html
+++ b/patterns/openshift-ai/getting-started/index.html
@@ -3740,7 +3740,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/openshift-ai/index.html b/patterns/openshift-ai/index.html
index 6c6b43466..cd3d76598 100644
--- a/patterns/openshift-ai/index.html
+++ b/patterns/openshift-ai/index.html
@@ -3743,7 +3743,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/rag-llm-gitops/getting-started/index.html b/patterns/rag-llm-gitops/getting-started/index.html
index 3ae2f4627..a26388f0d 100644
--- a/patterns/rag-llm-gitops/getting-started/index.html
+++ b/patterns/rag-llm-gitops/getting-started/index.html
@@ -3780,7 +3780,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/rag-llm-gitops/gpu_provisioning/index.html b/patterns/rag-llm-gitops/gpu_provisioning/index.html
index 9dd6dfbcb..69bfc2765 100644
--- a/patterns/rag-llm-gitops/gpu_provisioning/index.html
+++ b/patterns/rag-llm-gitops/gpu_provisioning/index.html
@@ -3856,7 +3856,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/rag-llm-gitops/index.html b/patterns/rag-llm-gitops/index.html
index 5791dff2a..9fe2bfd9f 100644
--- a/patterns/rag-llm-gitops/index.html
+++ b/patterns/rag-llm-gitops/index.html
@@ -3747,7 +3747,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/regional-dr/index.html b/patterns/regional-dr/index.html
new file mode 100644
index 000000000..c91f8c7c6
--- /dev/null
+++ b/patterns/regional-dr/index.html
@@ -0,0 +1,4937 @@
+<!doctype html><html><head><link rel=stylesheet href=https://validatedpatterns.io/sass/patternfly.css><link rel=stylesheet href=/css/custom.css><link rel=stylesheet href=https://validatedpatterns.io/sass/patternfly-addons.css><link rel=stylesheet href=https://use.fontawesome.com/releases/v6.3.0/css/solid.css><link rel=stylesheet href=https://use.fontawesome.com/releases/v6.3.0/css/fontawesome.css><link rel=stylesheet href=https://use.fontawesome.com/releases/v6.3.0/css/brands.css><title>Regional Disaster Recovery | Validated Patterns</title></head><body><div class=pf-c-page><header class=pf-c-page__header><div class=pf-c-page__header-brand><a href=/ class=pf-c-page__header-brand-link><img src=/images/validated-patterns.png alt="Validated Patterns"></a></div><div class=pf-c-page__header-tools><nav class="pf-c-nav pf-m-horizontal" role=navigation><ul class=pf-c-nav__list><li class="pf-c-nav__item pf-m-current"><a class=pf-c-nav__link href=/patterns/ title=Patterns>Patterns</a></li><li class=pf-c-nav__item><a class=pf-c-nav__link href=/learn/ title="Learn about Validated Patterns">Learn</a></li><li class=pf-c-nav__item><a class=pf-c-nav__link href=https://play.validatedpatterns.io title>Workshop</a></li><li class=pf-c-nav__item><a class=pf-c-nav__link href=/contribute/ title="Contribute to Validated Patterns">Contribute</a></li><li class=pf-c-nav__item><a class=pf-c-nav__link href=/blog/ title=Blog>Blog</a></li><li class=pf-c-nav__item><a class=pf-c-nav__link href=/ci/ title="CI Status">Status</a></li></ul></nav><form id=search action=https://validatedpatterns.io/search/ method=get><div class=pf-c-search-input><div class=pf-c-input-group><div class=pf-c-search-input__bar><span class=pf-c-search-input__text><span class=pf-c-search-input__icon><i class="fas fa-search fa-fw" aria-hidden=true></i>
+</span><input id=search-input name=query class=pf-c-search-input__text-input type=text placeholder=Search aria-label=Search></span></div><button form=search class="pf-c-button pf-m-control" type=submit aria-label=Search value=search>
+<i class="fas fa-arrow-right" aria-hidden=true></i></button></div></div></form></div></header><div class=pf-c-page__sidebar><div class=pf-c-page__sidebar-body><div class="pf-c-nav pf-m-light"><ul class=pf-c-nav__list><li class=pf-c-nav__item><a href=/patterns/ class=pf-c-nav__link><span class="pf-c-icon pf-m-md pf-m-inline"><span class=pf-c-icon__content><i class="fas fa-angle-left" aria-hidden=true></i>
+</span></span><span style=padding-left:10px>Back to Patterns</span></a></li><li class="pf-c-nav__item pf-m-expanded"><a href=https://validatedpatterns.io/patterns/regional-dr/ class="pf-c-nav__link pf-m-current">Regional Disaster Recovery</a></li></ul></div></div></div><main class=pf-c-page__main tabindex=0 data-bs-spy=scroll data-bs-target=#TableOfContents data-bs-offset=50><section class=pf-c-page__main-section><div class=pf-u-display-flex><div class=pf-c-content><div class="pf-c-panel pf-m-raised"><div class=pf-c-panel__main><div class=pf-c-panel__main-body><div class=pf-l-grid><div class="pf-l-grid__item pf-m-10-col"><h1 class="pf-c-title pf-m-4xl">Regional Disaster Recovery</h1></div><div class="pf-l-grid__item pf-m-2-col"><div class=pf-c-panel><div class=pf-c-panel__main><div class="pf-c-panel__main-body pf-u-text-align-right"><img src=/images/logos/regional-dr.png class=pattern_logo alt=Points></div></div></div></div><div class="pf-l-grid__item pf-m-3-col">Validation status:</div><div class="pf-l-grid__item pf-m-9-col"><span class="pf-c-label pf-m-orange"><span class=pf-c-label__content><img src=/images/pattern-tier-sandbox.png alt=Sandbox width=16 height=16 class=custom-pattern-icon>
+Sandbox</span></span></div><div class="pf-l-grid__item pf-m-3-col">Links:</div><div class="pf-l-grid__item pf-m-9-col"><ul class="pf-c-list pf-m-inline links-menu pf-m-align-self-center"><li class=pf-c-list__item><span class="pf-c-icon pf-m-inline"><span class="pf-c-list__item-icon pf-m-md"><i class="fa-sharp fa-regular fa-download"></i>
+</span></span><a href=https://github.com/validatedpatterns/regional-resiliency-pattern>Install</a></li><li class=pf-c-list__item><span class=pf-c-list__item-icon><i class="fa-solid fa-circle-question"></i>
+</span><a href=https://groups.google.com/g/validatedpatterns>Help & Feedback</a></li><li class=pf-c-list__item><span class=pf-c-list__item-icon><i class="fa-solid fa-bug"></i>
+</span><a href=https://github.com/validatedpatterns/regional-resiliency-pattern/issues>Report Bugs</a></li></ul></div></div></div></div></div><h1 id=openshift-regional-dr>OpenShift Regional DR</h1><h2 id=context>Context</h2><p>As more and more institution and mission critical organizations are moving
+in the cloud, the possible impact of having a provider failure, might this be
+only related to only one region, is very high.</p><p>This pattern is designed to prove the resiliency capabilities of Red Hat Openshift
+in such scenario.</p><p>The Regional Disaster Recovery Pattern, is designed to setup an multiple instances
+of Openshift Container Platform cluster connectedbetween them to prove multi-region
+resiliency by maintaing the application running in the event of a regional failure.</p><p>In this scenario we will be working in a Regional Disaster Recovery setup, and the
+synchronization parameters can be specified in the value file.</p><p>NOTE: please consider using longer times if you have a large dataset or very long
+distances between the clusters</p><h2 id=background>Background</h2><p>The <em>Regional DR Validated Pattern for <a href=https://www.redhat.com/en/technologies/cloud-computing/openshift>Red Hat OpenShift</a></em> increases the resiliency
+of your applications by connecting multiple clusters across different regions. This pattern
+uses <a href=https://www.redhat.com/en/technologies/management/advanced-cluster-management>Red Hat Advanced Cluster Management</a> to offer a
+<a href=https://www.redhat.com/en/technologies/cloud-computing/openshift-data-foundation>Red Hat OpenShift Data Foundation</a>-based multi-region disaster recovery plan if an
+entire region fails.</p><p><a href=https://www.redhat.com/en/technologies/cloud-computing/openshift-data-foundation>Red Hat OpenShift Data Foundation</a> offers two solutions for disaster
+recovery: <a href=https://docs.redhat.com/en/documentation/red_hat_openshift_data_foundation/4.16/html/configuring_openshift_data_foundation_disaster_recovery_for_openshift_workloads/metro-dr-solution>Metro DR</a> and <a href=https://docs.redhat.com/en/documentation/red_hat_openshift_data_foundation/4.16/html/configuring_openshift_data_foundation_disaster_recovery_for_openshift_workloads/rdr-solution>Regional DR</a>. As their name suggests, <em>Metro
+DR</em> refers to a metropolitan area disasters, which occur when the disaster
+covers only a single area in a region (availability zone), and <em>Regional DR</em>
+refers to when the entire region fails. Currently, only active-passive mode is
+supported.</p><p>A word on synchronization. A metropolitan network generally offers less latency;
+data can be written to multiple targets simultaneously, a feature required for
+active-active DR designs. On the other hand, writing to multiple targets in a
+cross-regional network might introduce unbearable latency to data
+synchronization and our applications. Therefore, <em>Regional DR</em> can only work
+with active-passive DR designs, where the targets are replicated
+asynchronously.</p><p>The synchronization between Availability Zones is faster and can be performed
+synchronous. However, in order don&rsquo;t include a lot of latency on the data
+synchronization process, when data is replicated across regions, it necessary
+includes latencies based on the distance between both regions (e.g. The latency
+between two regions on Europe, will always be less than between Europe and Asia,
+so consider this when designing your infrastructure deployment on the values
+files of the pattern). This is the main reason because this RegionalDR is
+configured in an Active-Passive mode.</p><p>It requires an already existing Openshift cluster, which will be used for installing the
+pattern, deploying active and passive clusters manage the application
+scheduling.</p><h3 id=prerequisites>Prerequisites</h3><p>Installing this pattern requires:</p><ul><li>One online <a href=https://www.redhat.com/en/technologies/cloud-computing/openshift>Red Hat OpenShift</a> cluster to become the &ldquo;Manager&rdquo; cluster.
+This cluster will orchestrate application deployments and data synchronizations.</li><li>Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager
+cluster. This is required for deploying the active and passive <a href=https://www.redhat.com/en/technologies/cloud-computing/openshift>OCP</a>
+clusters.</li><li><a href=https://docs.openshift.com/container-platform/4.14/cli_reference/openshift_cli/getting-started-cli.html>Red Hat OpenShift CLI</a> installed</li></ul><h3 id=solution-elements>Solution elements</h3><p>The <em>Regional DR Pattern</em> leverages <a href=https://www.redhat.com/en/technologies/cloud-computing/openshift-data-foundation>Red Hat OpenShift Data Foundation</a>&rsquo;s
+<a href=https://docs.redhat.com/en/documentation/red_hat_openshift_data_foundation/4.16/html/configuring_openshift_data_foundation_disaster_recovery_for_openshift_workloads/rdr-solution>Regional DR</a> solution, automating applications failover between
+<a href=https://www.redhat.com/en/technologies/management/advanced-cluster-management>Red Had Advanced Cluster Management</a> managed clusters in different regions.</p><ul><li>The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process</li><li>The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF</li><li>We have developed a DR trigger which will be used to start the DR process</li><li>The end user needs to configure which PV&rsquo;s need synchronization and the latencies</li><li>ACS Can be used for eventual policies</li><li>The clusters are connected by submariner and, to have a faster recovery time, we suggest having
+hybernated clusters ready to be used</li></ul><h3 id=red-hat-technologies>Red Hat Technologies</h3><ul><li><a href=https://www.redhat.com/en/technologies/cloud-computing/openshift>Red Hat Openshift Container Platform</a></li><li><a href=https://www.redhat.com/en/technologies/cloud-computing/openshift-data-foundation>Red Hat Openshift Data Foundation</a></li><li><a href=https://www.redhat.com/en/technologies/cloud-computing/openshift/gitops>Red Hat Openshift GitOps</a></li><li><a href=https://www.redhat.com/en/technologies/management/advanced-cluster-management>Red Hat Openshift Advanced Cluster Management</a></li><li><a href=https://www.redhat.com/en/technologies/cloud-computing/openshift/advanced-cluster-security-kubernetes>Red Hat Openshift Advanced Cluster Security</a></li></ul><h2 id=operators-and-technologies-this-pattern-uses>Operators and Technologies this Pattern Uses</h2><ul><li><a href=https://github.com/RHEcosystemAppEng/regional-dr-trigger-operator>Regional DR Trigger Operator</a></li><li><a href=https://submariner.io/>Submariner</a></li></ul><h2 id=tested-on>Tested on</h2><ul><li>Red Hat Openshift Container Platform v4.13</li><li>Red Hat Openshift Container Platform v4.14</li><li>Red Hat Openshift Container Platform v4.15</li></ul><h2 id=architecture>Architecture</h2><p>This section explains the architecture deployed by this Pattern and its Logical
+and Physical perspectives.
+<img src=/images/regional-resiliency-pattern/architecture-diagram-vp-regional-dr-v6.png alt=Regional-Resiliency-Pattern-Logical-Architecture></p><h2 id=logical-architecture>Logical architecture</h2><p><img src=/images/regional-resiliency-pattern/logical-architecture-diagram-vp-regional-dr-v6.png alt=Regional-Resiliency-Pattern-Logical-Architecture></p><h2 id=installation>Installation</h2><p>This patterns is designed to be installed in an Openshift cluster which will
+work as the orchestrator for the other clusters involved. The Adanced Cluster Manager
+installed will neither run the applications nor store any data from them, but it
+will take care of the plumbing of the various clusters involved,
+coordinating their communication and orchestrating when and where an application is
+going to be deployed.</p><p>As part of the pattern configuration, the administrator needs to define both
+clusters installation details as would be done using the Openshift-installer
+binary.</p><p>For installing the pattern, follow the next steps:</p><ol><li>Fork the <em>Pattern</em>.</li><li>Describe the instructions for creating the clusters and syncing data between them.</li><li>Commit and push your changes (to your fork).</li><li>Set your <strong>secret</strong> cloud provider credentials.</li><li>Connect to your target <em>Hub</em> cluster.</li><li>Install the <em>Pattern</em>.</li><li>Start deploying <a href=https://docs.redhat.com/en/documentation/red_hat_openshift_data_foundation/4.16/html/configuring_openshift_data_foundation_disaster_recovery_for_openshift_workloads/rdr-solution>resilient applications</a>.</li></ol><h3 id=pattern-configuration>Pattern Configuration</h3><p>For a full example, check the <em>Pattern</em>&rsquo;s <a href=https://github.com/validatedpatterns/regional-resiliency-pattern/blob/main/charts/hub/rdr/values.yaml>values.yaml</a>. The install-config
+specifications are detailed <a href=https://docs.openshift.com/container-platform/4.17/installing/installing_bare_metal_ipi/ipi-install-installation-workflow.html#additional-resources_config>here</a>.</p><p>Detailed configuration instructions can be found <a href="https://github.com/validatedpatterns/regional-resiliency-pattern?tab=readme-ov-file#installation">here</a>.</p><h2 id=owners>Owners</h2><p>For any request, bug report or comment about this pattern, please forward it to:</p><ul><li>Alejandro Villegas (<a href=mailto:avillega@rehat.com>avillega@rehat.com</a>)</li><li>Tomer Figenblat (<a href=mailto:tfigenbl@redhat.com>tfigenbl@redhat.com</a>)</li></ul></div><aside class="pf-c-jump-links pf-m-vertical sticky pf-m-expandable pf-m-non-expandable-on-2xl" aria-label="Table of contents"><div class="pf-l-stack pf-m-gutter"><div class="pf-l-stack__item pf-u-text-align-right"><a href=https://github.com/validatedpatterns/docs/commits/main/content/patterns/regional-dr/_index.md><span class="pf-c-icon pf-m-md" title="View page history"><span class=pf-c-icon__content><i class="fa-solid fa-clock-rotate-left"></i></span></span></a>
+<a href="https://issues.redhat.com/secure/CreateIssueDetails!init.jspa?pid=12325623&summary=Regional%20Disaster%20Recovery: %3C+Provide+a+brief+description+of+the+issue+%3E&issuetype=1&priority=10200&components=12365975&priority=10200&components=12365975&description=Link+to+page:+https%3a%2f%2fvalidatedpatterns.io%2fpatterns%2fregional-dr%2f+%0A+%0A+%3C+Provide+a+detailed+description+of+the+issue+with+link+to+the+docs++%3E"><span class="pf-c-icon pf-m-md" title="File a documentation bug"><span class=pf-c-icon__content><i class="fa-regular fa-bug"></i></span></span></a></div><div class=pf-l-stack__item><div class=pf-c-jump-links__header><div class=pf-c-jump-links__label><h1>Table of Contents</h1></div></div><nav id=TableOfContents><ul class=pf-c-jump-links__list><li class=pf-c-jump-links__item><a class=pf-c-jump-links__link href=#openshift-regional-dr>OpenShift Regional DR</a><ul class=pf-c-jump-links__list><li class=pf-c-jump-links__item><a class=pf-c-jump-links__link href=#context>Context</a></li><li class=pf-c-jump-links__item><a class=pf-c-jump-links__link href=#background>Background</a><ul class=pf-c-jump-links__list><li class=pf-c-jump-links__item><a class=pf-c-jump-links__link href=#prerequisites>Prerequisites</a></li><li class=pf-c-jump-links__item><a class=pf-c-jump-links__link href=#solution-elements>Solution elements</a></li><li class=pf-c-jump-links__item><a class=pf-c-jump-links__link href=#red-hat-technologies>Red Hat Technologies</a></li></ul></li><li class=pf-c-jump-links__item><a class=pf-c-jump-links__link href=#operators-and-technologies-this-pattern-uses>Operators and Technologies this Pattern Uses</a></li><li class=pf-c-jump-links__item><a class=pf-c-jump-links__link href=#tested-on>Tested on</a></li><li class=pf-c-jump-links__item><a class=pf-c-jump-links__link href=#architecture>Architecture</a></li><li class=pf-c-jump-links__item><a class=pf-c-jump-links__link href=#logical-architecture>Logical architecture</a></li><li class=pf-c-jump-links__item><a class=pf-c-jump-links__link href=#installation>Installation</a><ul class=pf-c-jump-links__list><li class=pf-c-jump-links__item><a class=pf-c-jump-links__link href=#pattern-configuration>Pattern Configuration</a></li></ul></li><li class=pf-c-jump-links__item><a class=pf-c-jump-links__link href=#owners>Owners</a></li></ul></li></ul></nav></div></div></aside></div></section><section id=prefooter class="pf-c-page__main-section footer-dark"><div class="pf-l-grid prefooter-menu-grid"><div class="pf-l-grid__item pf-m-12-col-on-sm pf-m-6-col-on-md pf-m-offset-1-col-on-md pf-u-mb-lg pf-u-mb-0-on-sm"><div class="pf-l-grid pf-u-py-xl"><div class="pf-l-grid__item pf-m-6-col-on-sm pf-m-4-col-on-md pf-u-ml-md pf-u-ml-0-on-md pf-u-mb-xl pf-u-mb-0-on-md"><p class="pf-c-title footer-menu-title">QUICKLINKS</p><nav aria-label="Quick Links"><ul class="pf-c-list pf-m-plain"><li><i class="prefooter-icon fa-brands fa-github"></i>
+<a class=footer-link aria-label="GitHub repository" href=https://github.com/validatedpatterns/docs>GitHub repository</a></li><li><i class="prefooter-icon fas fa-check-circle"></i>
+<a class=footer-link aria-label="Available patterns" href=/patterns>Available patterns</a></li></ul></nav></div><div class="pf-l-grid__item pf-m-6-col-on-sm pf-m-4-col-on-md pf-u-mt-lg pf-u-mt-0-on-sm pf-u-ml-md pf-u-ml-0-on-md pf-u-mb-xl pf-u-mb-0-on-md"><p class="pf-c-title footer-menu-title">CONTRIBUTE</p><nav aria-label=Contribute><ul class="pf-c-list pf-m-plain ws-org-pfsite-footer-menu-list"><li><i class="prefooter-icon fas fa-pen"></i>
+<a class=footer-link aria-label="Documentation contributor guidelines" href=/contribute/contribute-to-docs/>Documentation</a></li><li><i class="prefooter-icon fas fa-code"></i>
+<a class=footer-link aria-label="How to create a new pattern" href=/contribute/creating-a-pattern/>Patterns</a></li></ul></nav></div><div class="pf-l-grid__item pf-m-6-col-on-sm pf-m-4-col-on-md pf-u-mt-lg pf-u-mt-0-on-md pf-u-ml-md pf-u-ml-0-on-md"><p class="pf-c-title footer-menu-title">STAY IN TOUCH</p><nav aria-label="Stay in touch"><ul class="pf-c-list pf-m-plain"><li><i class="prefooter-icon fas fa-envelope"></i>
+<a href=https://groups.google.com/g/validatedpatterns class=footer-link target=top aria-label="Join the Validated Patterns mailing list">Mailing list</a></li></ul></nav></div></div></div><div class="pf-l-grid__item pf-m-12-col-on-sm pf-m-4-col-on-md"><div class="pf-l-grid pf-u-pt-xl"><div class="pf-l-grid__item pf-u-px-xl"><a class="pf-c-page__header-brand-link pf-c-brand pf-u-pb-md" href=/><img class=pf-c-brand src=/images/validated-patterns.png alt="Validated Patterns"></a><p class=footer-link>Validated Patterns are an evolution of how you deploy applications in a hybrid cloud. With a pattern, you can automatically deploy a full application stack through a GitOps-based framework. With this framework, you can create business-centric solutions while maintaining a level of Continuous Integration (CI) over your application.</p></div></div></div></div></section><footer id=footer class="footer-dark pf-m-no-fill pf-l-flex footer-center"><div class=pf-l-flex__item><a href=//www.redhat.com target=top aria-label="Visit Red Hat.com"><img src=/images/RHlogo.svg alt="Red Hat logo" width=145px height=613px></a><span class=site-copyright>Copyright &copy; 2024 Red Hat, Inc.</span></div><script src=/js/bootstrap.bundle.js></script><script>window.store={"https://validatedpatterns.io/learn/about-validated-patterns/":{title:"About Validated Patterns",tags:[],content:`Overview of Validated Patterns Validated Patterns are an advanced form of reference architectures that offer a streamlined approach to deploying complex business solutions. Validated Patterns are deployable, testable software artifacts with automated deployment, enhancing speed, reliability, and consistency across environments. These patterns are rigorously tested blueprints designed to meet specific business needs, reducing deployment risks.
+Building on traditional architectures, Validated Patterns focus on customer solutions involving multiple Red Hat products. Successful deployments serve as the foundation for these patterns, which include example applications and the necessary open source projects. Users can easily change these patterns to fit their specific needs.
+The creation process involves selecting customer use cases, validating the patterns with engineering teams, and developing GitOps-based automation. This automation supports Continuous Integration (CI) pipelines, allowing for proactive updates and maintenance as new product versions are released.
+Relationship to reference architectures Validated Patterns enhance reference architectures with automation and rigorous validation. Reference architectures provide a conceptual framework for building solutions. Validated Patterns take this further by offering a deployable software artifact that automates and optimizes the framework, ensuring consistent and efficient deployments. This approach allows businesses to implement complex solutions rapidly and with confidence, knowing that the patterns have been thoroughly tested and optimized for their use case.
+The problem Validated Patterns solve Deploying complex business solutions involves multiple steps, each of which, if done haphazardly, can introduce potential errors or inefficiencies. Validated Patterns address this by offering a pre-validated, automated deployment process. This reduces guesswork, minimizes manual intervention, and ensures faster, more reliable deployments. Organizations can then focus on strategic business objectives rather than deployment complexities.
+Validated Patterns goals The main goals of the Validated Patterns project include:
+Consistency: Ensure that deployments are uniform across different environments, reducing variability and potential issues.
+Reliability: Ensure that solutions are thoroughly tested and validated, minimizing the risk of errors during deployment.
+Efficiency: Reduce the time and resources required for deployment by providing pre-configured, automated solutions.
+Scalability: Enable businesses to deploy solutions that can scale to meet growing demands.
+Automation: Streamline the deployment of complex business solutions by automating key processes. While automation is a key aspect of the framework, its primary role is to support and enhance the core goals of consistency, reliability, efficiency, and scalability.
+Who should use Validated Patterns? Validated Patterns are particularly suited for IT architects, advanced developers, and system administrators with a familiarity with Kubernetes and the Red Hat OpenShift Container Platform. These patterns are ideal for those who need to deploy complex business solutions quickly and reliably across various environments. The framework incorporates advanced Cloud Native concepts and projects, such as OpenShift GitOps (ArgoCD), Advanced Cluster Management (Open Cluster Management), and OpenShift Pipelines (Tekton), making them especially beneficial for users familiar with these tools.
+Examples of Use Cases:
+Enterprise-Level Deployments: Organizations implementing large-scale, multi-tier applications can use Validated Patterns to ensure reliable and consistent deployments across all environments.
+Cloud Migration: Companies transitioning their infrastructure to the cloud can use Validated Patterns to automate and streamline the migration process.
+DevOps Pipelines: Teams relying on continuous integration and continuous deployment (CI/CD) pipelines can use Validated Patterns to automate the deployment of new features and updates, ensuring consistent and repeatable outcomes.
+The Validated Patterns community and ecosystem A vibrant community and ecosystem support and contribute to the ongoing development and refinement of Validated Patterns. This community-driven approach ensures that Validated Patterns stay current with the latest technological advancements and industry best practices. The ecosystem includes contributions from various industries and technology partners, ensuring that the patterns are applicable to a wide range of use cases and environments. This collaborative effort keeps the patterns relevant and fosters a culture of continuous improvement within the Red Hat ecosystem.
+Red Hat’s involvement in Validated Patterns Red Hat plays a pivotal role in the development, validation, and promotion of Validated Patterns. As a leader in open source solutions, Red Hat leverages its extensive expertise to create and maintain these patterns, ensuring they meet the highest standards of quality and reliability. Red Hat’s involvement extends beyond tool provision; it includes continuous updates to align these patterns with the latest technological advancements and industry needs. This ensures that organizations using Validated Patterns are always equipped with the most effective and up-to-date solutions available. Additionally, Red Hat collaborates closely with the community to expand the catalog of Validated Patterns, making these valuable resources accessible to organizations worldwide.
+Application deployment workflows Effective deployment workflows are crucial for ensuring that applications are deployed consistently and efficiently across various environments. By leveraging OpenShift clusters and automation tools, these workflows can streamline the process, reduce errors, and ensure scalability. Below, we outline the general structure for deploying applications, including edge patterns and GitOps integration.
+General structure All patterns assume you have an available OpenShift cluster for deploying applications. If you don’t have one, you can use cloud.redhat.com. The documentation uses the oc command syntax, but you can use kubectl interchangeably. For each deployment, ensure you’re logged into a cluster using the oc login command or by exporting the KUBECONFIG path.
+The following diagram outlines the general deployment flow for a data center application. Before proceeding, users must create a fork of the pattern repository to allow for changes to operational elements (such as configurations) and application code. These changes can then be successfully pushed to the forked repository as part of DevOps continuous integration (CI). Clone the repository to your local machine, and push future changes to your fork.
+In your fork, if needed, edit the values files, such as values-global.yaml or values-hub.yaml, to customize or personalize your deployment. These values files specify subscriptions, operators, applications, and other details. Additionally, each Validated Pattern contains a values-secret template file, which provides secret values required to successfully install the pattern. Patterns do not require committing secret material to git repositories. It is important to avoid pushing sensitive information to a public repository accessible to others. The Validated Patterns framework includes components to facilitate the safe use of secrets.
+Deploy the application as specified by the pattern, usually by using a make command (make install). When the workload is deployed, the pattern first deploys the Validated Patterns operator, which in turn installs OpenShift GitOps. OpenShift GitOps then ensures that all components of the pattern, including required operators and application code, are deployed.
+Most patterns also include the deployment of an Advanced Cluster Management (ACM) operator to manage multi-cluster deployments.
+Edge Patterns Many patterns include both a data center and one or more edge clusters. The following diagram outlines the general deployment flow for applications on an edge cluster. Edge OpenShift clusters are typically smaller than data center clusters and might be deployed on a three-node cluster that allows workloads on master nodes, or even on a single-node cluster (SNO). These edge clusters can be deployed on bare metal, local virtual machines, or in a public or private cloud.
+GitOps for edge After provisioning the edge cluster, import or join it with the hub or data center cluster. For more details on Instructions for importing the cluster see, Importing a cluster.
+After importing the cluster, ACM (Advanced Cluster Management) on the data center deploys an ACM agent and agent-addon pod into the edge cluster. ACM then installs OpenShift GitOps, which deploys the required applications based on the specified criteria.
+`,url:"https://validatedpatterns.io/learn/about-validated-patterns/",breadcrumb:"/learn/about-validated-patterns/"},"https://validatedpatterns.io/patterns/coco-pattern/coco-pattern-azure-requirements/":{title:"Azure requirements",tags:[],content:`Azure requirements This demo currently has been tested only on azure. The configuration tested used the openshift-install. OpenShift documentation contains details on how to do this.
+The documentation outlines minimum required configuration for an azure account.
+Changes required Do not accept default sizes for OpenShift install. It is recommended to up the workers to at least Standard_D8s_v5. This can be done by using openshift-install create install-config first and adjusting the workers under platform e.g.:
+- architecture: amd64 hyperthreading: Enabled name: worker platform: azure: type: Standard_D8s_v5 replicas: 3 On a cloud provider the virtual machines for the kata containers use &#34;peer pods&#34; which are running directly on the cloud provider’s hypervisor (see the diagram below). This means that access is required to the &#34;confidential computing&#34; virtual machine class. On Azure the Standard_DCas_v5 class of virtual machines are used. These virtual machines are NOT available in all regions. Users will also need to up the specific limits for Standard_DC2as_v5 virtual machines.
+DNS for the openshift cluster also MUST be provided by azure DNS.
+Azure configuration required for the validated pattern The validated pattern requires access to azure apis to provision peer-pod VMs and to obtain certificates from let’s encrypt.
+Azure configuration information must be provided in two places:
+The a secret must be loaded using a ../../../learn/secrets-management-in-the-validated-patterns-framework/[values-secret] file. The values-secret.yaml.template file provides the appropriate structure
+A broader set of information about the cluster is required in values-global.yaml (see below).
+global: azure: clientID: &#39;&#39; # Service principle ID subscriptionID: &#39;&#39; tenantID: &#39;&#39; # Tenant ID DNSResGroup: &#39;&#39; # Resource group for the azure DNS hosted zone hostedZoneName: &#39;&#39; # the hosted zone name clusterResGroup: &#39;&#39; # Resource group of the cluster clusterSubnet: &#39;&#39; # subnet of the cluster clusterNSG: &#39;&#39; # network security group of the worker nodes in the cluster clusterRegion: &#39;&#39; `,url:"https://validatedpatterns.io/patterns/coco-pattern/coco-pattern-azure-requirements/",breadcrumb:"/patterns/coco-pattern/coco-pattern-azure-requirements/"},"https://validatedpatterns.io/contribute/contribute-to-docs/":{title:"Contributor's guide",tags:[],content:` Contribute to Validated Patterns documentation Different ways to contribute There are a few different ways you can contribute to Validated Patterns documentation:
+Email the Validated Patterns team at hybrid-cloud-patterns@googlegroups.com.
+Create a GitHub or Jira issue .
+Submit a pull request (PR). To create a PR, create a local clone of your own fork of the Validated Patterns docs repository, make your changes, and submit a PR. This option is best if you have substantial changes.
+Contribution workflow When you submit a PR, the Validated Patterns Docs team reviews the PR and arranges further reviews by Quality Engineering (QE), subject matter experts (SMEs), and others, as required. If the PR requires changes, updates, or corrections, the reviewers add comments in the PR. The documentation team merges the PR after you have implemented all feedback, and you have squashed all commits.
+Repository organization ├── archetypes ├── content │ └── blog | └── contribute | └── learn | └── patterns | └── multicloud-gitops | | └──_index.adoc | | └──mcg-getting-started.adoc | | | └── medical-diagnosis | └──_index.adoc | └── medical-diagnosis-assembly.adoc ├── layouts │ └── _default | └── blog ├── modules │ └── multicloud-gitops-logical-architecture.adoc │ └── multicloud-gitops-physical-architecture.adoc ├── static | └── images ├── themes/patternfly ├── config.yaml └── README.adoc Install and set up the tools and software Create a GitHub account Before you can contribute to Validated Patterns documentation, you must sign up for a GitHub account.
+Set up authentication When you have your account set up, follow the instructions to generate and set up SSH keys on GitHub for authentication between your workstation and GitHub.
+Confirm authentication is working correctly with the following command:
+$ ssh -T git@github.com Fork and clone the Validated Patterns documentation repository You must fork and set up the Validated Patterns documentation repository on your workstation so that you can create PRs and contribute. These steps must only be performed during initial setup.
+Fork the https://github.com/validatedpatterns/docs repository into your GitHub account from the GitHub UI. Click Fork in the upper right-hand corner.
+In the terminal on your workstation, change into the directory where you want to clone the forked repository.
+Clone the forked repository onto your workstation with the following command, replacing &lt;user_name&gt; with your actual GitHub username.
+$ git clone git@github.com:&lt;user_name&gt;/docs.git Change into the directory for the local repository you just cloned.
+$ cd docs Add an upstream pointer back to the Validated Patterns’s remote repository, in this case docs.
+$ git remote add upstream git@github.com:validatedpatterns/docs.git This ensures that you are tracking the remote repository to keep your local repository in sync with it.
+Install Asciidoctor The Validated Patterns documentation is created in AsciiDoc language, and is processed with AsciiDoctor, which is an AsciiDoc language processor.
+Prerequisites The following are minimum requirements:
+A bash shell environment (Linux and OS X include a bash shell environment)
+A web browser (Mozilla Firefox, Google Chrome, or Safari)
+Web browser add-ons (preview only)
+An editor that can strip trailing whitespace
+An Asciidoctor installer
+Preview the documentation using a container image You can use the container image to build the Validated Patterns documentation, locally. To do so, ensure that you have installed the make and podman tools.
+In the terminal window, navigate to the local instance of the validatedpatterns/docs repository and run the following command:
+$ make serve Verification A preview is available on your browser at localhost:4000.
+Documentation guidelines Documentation guidelines for contributing to the Validated Patterns Docs
+General guidelines When authoring content, follow these style guides:
+Red Hat Supplementary Style Guide
+IBM Style, especially word usage
+When asked for an IBMid, Red Hat associates can use their Red Hat e-mail. Modular documentation reference guide
+Modular documentation templates
+Modular documentation terms Modular doc entity Description Asssembly
+An assembly is a collection of modules that describes how to accomplish a user story.
+Concept module
+A concept contains information to support the tasks that users want to do and must not include task information like commands or numbered steps. In most cases, create your concepts as individual modules and include them in appropriate assemblies. Avoid using gerunds in concept titles. &#34;About &lt;concept&gt;&#34; is a common concept module title.
+Procedure module
+A procedure contains the steps that users follow to complete a process or task. Procedures contain ordered steps and explicit commands. In most cases, create your procedures as individual modules and include them in appropriate assemblies. Use a gerund in the procedure title, such as &#34;Creating&#34;.
+Reference module
+A reference module provides data that users might want to look up, but do not need to remember. A reference module has a very strict structure, often in the form of a list or a table. A well-organized reference module enables users to scan it quickly to find the details they want.
+Naming conventions for assembly and module files Use lowercase separated by dash. Create assembly and module file names that accurately and closely reflect the title of the assembly or module.
+Examples designing-guided-decision-tables.adoc (Assembly of guided decision table modules)
+guided-decision-tables.adoc (Concept module)
+creating-guided-decision-tables.adoc (Procedure module for creating)
+guided-decision-table-examples.adoc (Reference module with examples)
+Content type attributes Each .adoc file must contain a :_content-type: attribute in its metadata that indicates its file type. This information is used by some publication processes to sort and label files.
+Add the attribute from the following list that corresponds to your file type:
+:_content-type: ASSEMBLY
+:_content-type: CONCEPT
+:_content-type: PROCEDURE
+:_content-type: REFERENCE
+See, Assembly file metadata and Module file metadata.
+Naming conventions for directories Use lowercase. For directory with a multiple-word name, use lowercase separated by dash, for example multicloud-gitops.
+Language and grammar Consider the following guidelines:
+Use present tense.
+Use active voice.
+Use second person perspective (you).
+Avoid first person perspective (I, we, us).
+Be gender neutral.
+Use the appropriate tone.
+Write for a global audience.
+Titles and headings Use sentence-style capitalization in all titles and section headings. Ensure that titles focus on customer tasks instead of the product.
+For assemblies and procedure modules, use a gerund form in headings, such as:
+Creating
+Managing
+Using
+For modules that do not include any procedure, use a noun phrase, for example Red Hat Process Automation Manager API reference.
+Writing assemblies For more information about forming assemblies, see the Red Hat modular docs reference guide and the assembly template.
+Assembly file metadata Every assembly file should contain the following metadata at the top, with no line spacing in between, except where noted:
+:_content-type: ASSEMBLY (1) [id=&#34;&lt;unique-heading-for-assembly&gt;&#34;] (2) = Assembly title (3) include::_common-docs/common-attributes.adoc[] (4) :context: &lt;unique-context-for-assembly&gt; (5) (6) :toc: (7) 1 The content type for the file. For assemblies, always use :_content-type: ASSEMBLY. Place this attribute before the anchor ID or, if present, the conditional that contains the anchor ID. 2 A unique anchor ID for this assembly. Use lowercase. Example: cli-developer-commands 3 Human readable title (notice the &#39;=&#39; top-level header) 4 Includes attributes common to Validated Patterns docs. 5 Context used for identifying headers in modules that is the same as the anchor ID. Example: cli-developer-commands. 6 A blank line. You must have a blank line here before the toc. 7 The table of contents for the current assembly. After the heading block and a single whitespace line, you can include any content for this assembly.
+Writing modules For more information about creating modules, see the Red Hat Modular documentation reference guide.
+Module file metadata Every module should be placed in the modules folder and should contain the following metadata at the top:
+// * list of assemblies where this module is included (1) :_content-type: &lt;TYPE&gt; (2) [id=&#34;&lt;module-anchor&gt;_{context}&#34;] (3) = Module title (4) 1 The content type for the file. Replace &lt;TYPE&gt; with the actual type of the module, CONCEPT, REFERENCE, or PROCEDURE. Place this attribute before the anchor ID or, if present, the conditional that contains the anchor ID. 2 List of assemblies in which this module is included. 3 A module anchor with {context} that must be lowercase and must match the module’s file name. The {context} variable must be preceded by an underscore (_) when declared in an anchor ID. 4 Human readable title. To ensure consistency in the results of the leveloffset values in include statements, you must use a level one heading ( = ) for the module title. Example:
+// Module included in the following assemblies: // // * cli_reference/developer-cli-commands.adoc :_content-type: REFERENCE [id=&#34;cli-basic-commands_{context}&#34;] = Basic CLI commands Attribute files AsciiDoc attributes are variables you can use in common files to:
+avoid hard-coding brand-specific information,
+share content between multiple brands more easily.
+All attribute files must be placed in the a separate attributes file. For example, common-docs directory.
+It is acceptable to group related attributes in the common-attributes.adoc file under a comment, as shown in the following example:
+//ACM rh-rhacm-product: Red Hat Advanced Cluster Management (RHACM) :rh-shortname: RHACM //GitOps :gitops-product: Red Hat OpenShift GitOps :gitops-shortname: GitOps For more information on attributes, see link: https://docs.asciidoctor.org/asciidoc/latest/key-concepts/#attributes.
+Formatting Use the following links to refer to AsciiDoc markup and syntax.
+AsciiDoc Mark-up Quick Reference for Red Hat Documentation
+AsciiDoc Syntax Quick Reference
+If you are graduating to AsciiDoc from Markdown, see the AsciiDoc to Markdown syntax comparison by example.
+Formatting commands and code blocks To enable syntax highlighting, use [source,terminal] for any terminal commands, such as oc commands and their outputs. For example:
+[source,terminal] ---- $ oc get nodes ---- To enable syntax highlighting for a programming language, use [source] tags used in the code block. For example:
+[source,yaml]
+[source,go]
+[source,javascript]
+`,url:"https://validatedpatterns.io/contribute/contribute-to-docs/",breadcrumb:"/contribute/contribute-to-docs/"},"https://validatedpatterns.io/patterns/coco-pattern/coco-pattern-getting-started/":{title:"Getting started",tags:[],content:` Deploying Install an OpenShift Cluster on Azure
+Update the required Azure configuration and secrets
+./pattern.sh make install
+Wait: The cluster needs to reboot all nodes at least once, and reprovision the ingress to use the let’s encrypt certificates.
+If the services do not come up use the ArgoCD UI to triage potential timeouts.
+Simple Confidential container tests The pattern deploys some simple tests of CoCo with this pattern. A &#34;Hello Openshift&#34; (e.g. curl to return &#34;Hello Openshift!&#34;) application has been deployed in three form factor.
+A vanilla kubernetes pod at oc get pods -n hello-openshift standard
+A confidential container oc get pods -n hello-openshift secure
+A confidential container with a relaxed policy at oc get pods -n hello-openshift insecure-policy
+In this case the insecure policy is designed to allow a user to be able to exec into the confidential container. Typically this is disabled by an immutable policy established at pod creation time.
+Doing a oc get pods for either of the pods running a confidential container should show the runtimeClassName: kata-remote for the pod.
+Logging into azure once the pods have been provisioned will show that each of these two pods has been provisioned with it’s own Standard_DC2as_v5 virtual machine.
+oc exec testing In a OpenShift cluster without confidential containers, Role Based Access Control (RBAC), may be used to prevent users from execing into a container to mutate it. However:
+Cluster admins can always circumvent this capability
+Anyone logged into the node directly can also circumvent this capability.
+Confidential containers can prevent this. Running: oc exec -n hello-openshift -it secure — bash will result in a denial of access, irrespective of the user undertaking the action, including kubeadmin. For running this with either the standard pod oc exec -n hello-openshift -it standard — bash, or the CoCo pod with the policy disabled oc exec -n hello-openshift -it insecure-policy — bash will allow shell access.
+Confidential Data Hub testing Part of the CoCo VM is a component called the Confidential Data Hub (CDH), which simplifies access to the Trustee Key Broker service for end applications. Find out more about how the CDH and Trustee work together here.
+The CDH presents to containers within the pod (only), via a localhost URL. The CoCo container with an insecure policy can be used for testing the behaviour.
+oc exec -n hello-openshift -it insecure-policy — bash to get a shell into a confidential container
+Trustee’s configuration specifies the list of secrets which the KBS can access with the kbsSecretResources attribute.
+Secrets within the CDH can be accessed (by default) at http://127.0.0.1:8006/cdh/resource/default/$K8S_SECRET/$K8S_SECRET_KEY.
+In this case http://127.0.0.1:8006/cdh/resource/default/passphrase/passphrase by default will return a string which was randomly generated when the pattern was deployed.
+This should be the same as result as oc get secrets -n trustee-operator-system passphrase -o yaml | yq &#39;.data.passphrase&#39; | base64 -d\`
+Tailing the logs for the kbs container e.g. oc logs -n trustee-operator-system kbs-deployment-5b574bccd6-twjxh -f shows the evidence which is flowing to the KBS from the CDH.
+`,url:"https://validatedpatterns.io/patterns/coco-pattern/coco-pattern-getting-started/",breadcrumb:"/patterns/coco-pattern/coco-pattern-getting-started/"},"https://validatedpatterns.io/patterns/emerging-disease-detection/edd-getting-started/":{title:"Getting started",tags:[],content:` Deploying the Emerging Disease Detection pattern Prerequisites An OpenShift cluster (Go to the OpenShift console). Cluster must have a dynamic StorageClass to provision PersistentVolumes.
+A GitHub account (and a token for it with repositories permissions, to read from and write to your forks)
+For installation tooling dependencies, see Patterns quick start.
+The use of this pattern depends on having a Red Hat OpenShift cluster. In this version of the validated pattern there is no dedicated Hub / Edge cluster for the Emerging Disease Detection pattern. This single node pattern can be extend as a managed cluster(s) to a central hub.
+If you do not have a running Red Hat OpenShift cluster you can start one on a public or private cloud by using Red Hat’s cloud service.
+Utilities A number of utilities have been built by the validated patterns team to lower the barrier to entry for using the community or Red Hat Validated Patterns. To use these utilities you will need to export some environment variables for your cloud provider:
+Preparation Fork the emerging-disease-detection repo on GitHub. It is necessary to fork because your fork will be updated as part of the GitOps and DevOps processes.
+Clone the forked copy of this repository.
+git clone git@github.com:&lt;your-username&gt;/emerging-disease-detection.git Create a local copy of the Helm secrets values file that can safely include credentials
+DO NOT COMMIT THIS FILE
+You do not want to push credentials to GitHub.
+cp values-secret.yaml.template ~/values-secret.yaml vi ~/values-secret.yaml values-secret.yaml example
+secrets: - name: rhpam vaultPrefixes: - global fields: - name: rhpam_api_passwd value: kieserver - name: sso_siteadmin_password value: r3dh4t1! - name: kie_admin_password value: admin - name: kieserver_user_password value: kieserver - name: psql_passwd value: rhpam - name: fhir-psql-db vaultPrefixes: - global fields: - name: psql_credentials_secret value: psql_secret - name: psql_user_name value: fhir - name: psql_user_passwd value: fhir When you edit the file you can make changes to the various DB and Grafana passwords if you wish.
+Customize the values-global.yaml for your deployment
+git checkout -b my-branch vi values-global.yaml Replace instances of PROVIDE_ with your specific configuration
+global: pattern: emerging-disease-detection hubClusterDomain: &#34;AUTO&#34; # this is for test only This value is automatically fetched when Invoking against a cluster options: useCSV: false syncPolicy: Automatic installPlanApproval: Automatic main: clusterGroupName: hub gitOpsSpec: operatorChannel: gitops-1.9 git add values-global.yaml git commit values-global.yaml git push origin my-branch You can deploy the pattern using the validated pattern operator. If you do use the operator then skip to Validating the Environment below.
+Preview the changes that will be made to the Helm charts.
+./pattern.sh make show Login to your cluster using oc login or exporting the KUBECONFIG
+oc login or set KUBECONFIG to the path to your kubeconfig file. For example export KUBECONFIG=~/my-ocp-env/auth/kubeconfig Check the values files before deployment You can run a check before deployment to make sure that you have the required variables to deploy the Emerging Disease Detection Validated Pattern.
+You can run make predeploy to check your values. This will allow you to review your values and changed them in the case there are typos or old values. The values files that should be reviewed prior to deploying the Emerging Disease Detection Validated Pattern are:
+Values File Description values-secret.yaml / values-secret-emerging-disease-detection.yaml
+This is the values file that will include the rhpam and fhir-psql-db sections with all database et al secrets
+values-global.yaml
+File that is used to contain all the global values used by Helm
+Deploy Apply the changes to your cluster
+./pattern.sh make install If the install fails and you go back over the instructions and see what was missed and change it, then run make update to continue the installation.
+This takes some time. Especially for the OpenShift Data Foundation operator components to install and synchronize. The make install provides some progress updates during the install. It can take up to twenty minutes. Compare your make install run progress with the following video showing a successful install.
+Check that the operators have been installed in the UI.
+To verify, in the OpenShift Container Platform web console, navigate to Operators → Installed Operators page.
+Check that the Operator is installed in the openshift-operators namespace and its status is Succeeded.
+Using OpenShift GitOps to check on Application progress You can also check on the progress using OpenShift GitOps to check on the various applications deployed.
+Obtain the ArgoCD URLs and passwords.
+The URLs and login credentials for ArgoCD change depending on the pattern name and the site names they control. Follow the instructions below to find them, however you choose to deploy the pattern.
+Display the fully qualified domain names, and matching login credentials, for all ArgoCD instances:
+ARGO_CMD=\`oc get secrets -A -o jsonpath=&#39;{range .items[*]}{&#34;oc get -n &#34;}{.metadata.namespace}{&#34; routes; oc -n &#34;}{.metadata.namespace}{&#34; extract secrets/&#34;}{.metadata.name}{&#34; --to=-\\\\n&#34;}{end}&#39; | grep gitops-cluster\` CMD=\`echo $ARGO_CMD | sed &#39;s|- oc|-;oc|g&#39;\` eval $CMD The result should look something like:
+NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD hub-gitops-server hub-gitops-server-emerging-disease-detection-hub.apps.wh-edd-cluster.aws.validatedpatterns.com hub-gitops-server https passthrough/Redirect None # admin.password xsyYU6eSWtwniEk1X3jL0c2TGfQgVpDH NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD cluster cluster-openshift-gitops.apps.wh-edd-cluster.aws.validatedpatterns.com cluster 8080 reencrypt/Allow None kam kam-openshift-gitops.apps.wh-edd-cluster.aws.validatedpatterns.com kam 8443 passthrough/None None openshift-gitops-server openshift-gitops-server-openshift-gitops.apps.wh-edd-cluster.aws.validatedpatterns.com openshift-gitops-server https passthrough/Redirect None # admin.password FdGgWHsBYkeqOczE3PuRpU1jLn7C2fD6 The most important ArgoCD instance to examine at this point is emerging-disease-detection-hub. This is where all the applications for the pattern can be tracked.
+Check all applications are synchronised. There are thirteen different ArgoCD &#34;applications&#34; deployed as part of this pattern.
+Viewing the Sepsis Detection dashboard TO-DO: Describe how to examine the various parts of the Sepsis application
+Next Steps Help &amp; Feedback Report Bugs
+Using the Emerging Disease Detection pattern The following steps describes how you can use this pattern in a demo.
+Viewing the Sepsis Detection dashboard TO-DO: Describe how to examine the various parts of the Sepsis application
+`,url:"https://validatedpatterns.io/patterns/emerging-disease-detection/edd-getting-started/",breadcrumb:"/patterns/emerging-disease-detection/edd-getting-started/"},"https://validatedpatterns.io/patterns/gaudi-rag-chat-qna/gaudi-rag-chat-qna-getting-started/":{title:"Getting started",tags:[],content:`Deploying the OPEA QnA chat accelerated with Intel Gaudi pattern Prerequisites An OpenShift Container Platform cluster
+To create an OpenShift Container Platform cluster, go to the Red Hat Hybrid Cloud console and select Services -&gt; Containers -&gt; Create cluster.
+The cluster must have a dynamic StorageClass to provision PersistentVolumes. It was tested with ODF (OpenShift Data Foundation) or LVM Storage solutions. CephFS should be set as a default Storage Class - Setup Guide
+Required hardware.
+OpenShift Container Platform Cluster must have a configured Image Registry - Setup Guide
+A GitHub account and a token for it with repositories permissions, to read from and write to your forks.
+A HuggingFace account and User Access token, which allows to download AI models. More about User Access token can be found on official HuggingFace website
+Install the tooling dependencies.
+Install AWS CLI tool to check status of S3 bucket (RGW storage).
+If you do not have a running Red Hat OpenShift cluster, you can start one on a public or private cloud by using Red Hat Hybrid Cloud Console.
+Procedure Fork the qna-chat-gaudi repository on GitHub.
+Clone the forked copy of this repository.
+git clone git@github.com:your-username/qna-chat-gaudi.git Create a local copy of the secret values file that can safely include credentials. Run the following commands:
+cp values-secret.yaml.template ~/values-gaudi-rag-chat-qna.yaml vi ~/values-gaudi-rag-chat-qna.yaml Do not commit this file. You do not want to push personal credentials to GitHub. If you do not want to customize the secrets by copying secret, these steps are not needed. User can just type in required HuggingFace User Access Token while installing pattern. In the beginning of the installation process there should appear prompt asking for the HuggingFace User Access Token.
+(Optional) If cluster is behind proxy values-global.yaml should be similar to the following:
+If the cluster is behind proxy remember to change proxy values of fields gaudillm.build_envs and gaudillm.runtime_envs in values-global.yaml file to appropriate ones.
+gaudillm: namespace: gaudi-llm build_envs: - name: http_proxy value: http://proxy-internal.cluster1.gaudi.internal:912 - name: https_proxy value: http://proxy-internal.cluster1.gaudi.internal:912 - name: HTTP_PROXY value: http://proxy-internal.cluster1.gaudi.internal:912 - name: HTTPS_PROXY value: http://proxy-internal.cluster1.gaudi.internal:912 - name: no_proxy value: .cluster.local,.gaudi.internal,.cluster1.gaudi.internal,.svc,192.168.122.0/24,10.128.0.0/14,127.0.0.1,172.30.0.0/16,api-int.cluster1.gaudi.internal,localhost - name: NO_PROXY value: .cluster.local,.gaudi.internal,.cluster1.gaudi.internal,.svc,192.168.122.0/24,10.128.0.0/14,127.0.0.1,172.30.0.0/16,api-int.cluster1.gaudi.internal,localhost runtime_envs: - name: http_proxy value: http://proxy-internal.cluster1.gaudi.internal:912 - name: https_proxy value: http://proxy-internal.cluster1.gaudi.internal:912 - name: HTTP_PROXY value: http://proxy-internal.cluster1.gaudi.internal:912 - name: HTTPS_PROXY value: http://proxy-internal.cluster1.gaudi.internal:912 - name: no_proxy value: .cluster.local,.gaudi.internal,.cluster1.gaudi.internal,.svc,192.168.122.0/24,10.128.0.0/14,127.0.0.1,172.30.0.0/16,api-int.cluster1.gaudi.internal,localhost - name: NO_PROXY value: .cluster.local,.gaudi.internal,.cluster1.gaudi.internal,.svc,192.168.122.0/24,10.128.0.0/14,127.0.0.1,172.30.0.0/16,api-int.cluster1.gaudi.internal,localhost Customize the deployment for your cluster. Run the following command:
+git checkout -b my-branch vi values-global.yaml git add values-global.yaml git commit values-global.yaml git push origin my-branch Deploy the pattern by running ./pattern.sh make install or by using the Validated Patterns Operator.
+If you have not set HuggingFace token in secrets file there will be prompt to set the token.
+Deploying the cluster by using the pattern.sh file To deploy the cluster by using the pattern.sh file, complete the following steps:
+Login to your cluster by running the following command:
+oc login Optional: Set the KUBECONFIG variable for the kubeconfig file path:
+export KUBECONFIG=~/&lt;path_to_kubeconfig&gt; Deploy the pattern to your cluster. Run the following command:
+./pattern.sh make install In the beginning of installation there should be prompt to enter HuggingFace token, looking like this:
+Insert HuggingFace Token: Validated Pattern can take a while to be fully installed as it requires couple of reboots to apply MachineConfigs for worker nodes.
+As part of this pattern, HashiCorp Vault has been installed. Refer to the section on Vault.
+Verification Verify that the Operators have been installed.
+To verify, in the OpenShift Container Platform web console, navigate to Operators → Installed Operators page.
+Check that the Operators are installed in the openshift-operators namespace and its status is Succeeded.
+Verify that S3 bucket was created successfully. Run following commands:
+export AWS_ACCESS_KEY_ID=$(oc -n openshift-storage get secret s3-secret-bck -ojsonpath=&#39;{.data.AWS_ACCESS_KEY_ID}&#39; | base64 -d) export AWS_SECRET_ACCESS_KEY=$(oc -n openshift-storage get secret s3-secret-bck -ojsonpath=&#39;{.data.AWS_SECRET_ACCESS_KEY}&#39; | base64 -d) export CEPH_RGW_ENDPOINT=http://$(oc -n openshift-storage get route s3-rgw -ojsonpath=&#39;{.spec.host}&#39;) aws --endpoint \${CEPH_RGW_ENDPOINT} s3api list-buckets Expected response should show that bucket named model-bucket exists:
+{ &#34;Buckets&#34;: [ { &#34;Name&#34;: &#34;model-bucket&#34;, &#34;CreationDate&#34;: &#34;2024-06-27T08:44:09.451000+00:00&#34; } ], &#34;Owner&#34;: { &#34;DisplayName&#34;: &#34;ocs-storagecluster&#34;, &#34;ID&#34;: &#34;ocs-storagecluster-cephobjectstoreuser&#34; } } Verify that MachineConfigPool is ready. To check the status run following command:
+oc get mcp Verify that all applications are healthy and synchronized. Under the project gaudi-rag-chat-qna click the URL for the hub gitops server.
+Setup Red Hat OpenShift AI After all components are properly deployed user can proceed to setup Red Hat OpenShift AI. The procedures consists of two manual steps:
+Uploading AI model to S3 bucket (RGW storage) on the cluster
+Deploying TGI
+Upload AI model First step is to go to RHOAI dashboard/Data Science Projects tab and select gaudi-llm project (If the gaudi-llm project is missing user should check if app is ready in ArgoCD dashboard):
+Go to Workbenches tab and click Create workbench:
+Fill the input form following images below:
+After workbench is created go to this Jupyter notebook dashboard and upload Jupyter notebook file /download-model.ipynb to the file explorer so it looks like this:
+When download-model is uploaded, run notebook’s all commands. After notebook is executed, model should be uploaded to S3 bucket. To check if model is present please run following commands:
+export AWS_ACCESS_KEY_ID=$(oc -n openshift-storage get secret s3-secret-bck -ojsonpath=&#39;{.data.AWS_ACCESS_KEY_ID}&#39; | base64 -d) export AWS_SECRET_ACCESS_KEY=$(oc -n openshift-storage get secret s3-secret-bck -ojsonpath=&#39;{.data.AWS_SECRET_ACCESS_KEY}&#39; | base64 -d) export CEPH_RGW_ENDPOINT=http://$(oc -n openshift-storage get route s3-rgw -ojsonpath=&#39;{.spec.host}&#39;) aws --endpoint \${CEPH_RGW_ENDPOINT} s3 ls model-bucket/models/ Response should show that model directory is present.
+Deploy TGI First step is to go to RHOAI dashboard/Data Science Projects tab and select gaudi-llm project:
+Now select Data connections tab and click Add data connection:
+There should appear form Add data connection with couple of inputs. Form should be looking similar to this:
+To get value for Access key run command:
+oc -n openshift-storage get secret s3-secret-bck -ojsonpath=&#39;{.data.AWS_ACCESS_KEY_ID}&#39; | base64 -d To get value for Secret key run command:
+oc -n openshift-storage get secret s3-secret-bck -ojsonpath=&#39;{.data.AWS_SECRET_ACCESS_KEY}&#39; | base64 -d To get value for Endpoint run command:
+echo &#34;http://$(oc -n openshift-storage get route s3-rgw -ojsonpath=&#39;{.spec.host}&#39;)&#34; Next step is to go to tab Models and click Deploy model in Single-model serving platform section:
+There should appear form Deploy model. Fill all the inputs like in following images and then click Deploy button:
+If everything is setup correctly go to tab Models again to check status of TGI. It should be looking like this:
+RAG Chat demo After whole setup is complete demo application is ready to use. Chat QnA UI address can be obtained by running following command:
+echo &#34;http://$(oc -n gaudi-llm get route chatqna-gaudi-ui-server -ojsonpath=&#39;{.spec.host}&#39;)&#34; `,url:"https://validatedpatterns.io/patterns/gaudi-rag-chat-qna/gaudi-rag-chat-qna-getting-started/",breadcrumb:"/patterns/gaudi-rag-chat-qna/gaudi-rag-chat-qna-getting-started/"},"https://validatedpatterns.io/patterns/mlops-fraud-detection/mfd-getting-started/":{title:"Getting started",tags:[],content:` Deploying the MLOps Fraud Detection pattern Prerequisites An OpenShift cluster (Go to the OpenShift console). Cluster must have a dynamic StorageClass to provision PersistentVolumes.
+A GitHub account (and a token for it with repositories permissions, to read from and write to your forks)
+For installation tooling dependencies, see Patterns quick start.
+The use of this pattern depends on having a Red Hat OpenShift cluster. In this version of the validated pattern there is no dedicated Hub / Edge cluster for the MLOps Fraud Detection pattern. This single node pattern can be extend as a managed cluster(s) to a central hub.
+If you do not have a running Red Hat OpenShift cluster you can start one on a public or private cloud by using Red Hat’s cloud service.
+Utilities A number of utilities have been built by the validated patterns team to lower the barrier to entry for using the community or Red Hat Validated Patterns. To use these utilities you will need to export some environment variables for your cloud provider:
+Preparation Fork the mlops-fraud-detection repo on GitHub. It is necessary to fork because your fork will be updated as part of the GitOps and DevOps processes.
+Clone the forked copy of this repository.
+git clone git@github.com:&lt;your-username&gt;/mlops-fraud-detection.git Create a local copy of the Helm secrets values file that can safely include credentials
+DO NOT COMMIT THIS FILE
+You do not want to push credentials to GitHub.
+cp values-secret-mlops-fraud-detection.yaml.template ~/values-secret.yaml vi ~/values-secret.yaml values-secret.yaml example
+secrets: //Nothing at time of writing. When you edit the file you can make changes to the various DB and Grafana passwords if you wish.
+Customize the values-global.yaml for your deployment
+git checkout -b my-branch vi values-global.yaml Replace instances of PROVIDE_ with your specific configuration
+global: pattern: mlops-fraud-detection hubClusterDomain: &#34;AUTO&#34; # this is for test only This value is automatically fetched when Invoking against a cluster options: useCSV: false syncPolicy: Automatic installPlanApproval: Automatic main: clusterGroupName: hub git add values-global.yaml git commit values-global.yaml git push origin my-branch You can deploy the pattern using the validated pattern operator. If you do use the operator then skip to Validating the Environment below.
+Preview the changes that will be made to the Helm charts.
+./pattern.sh make show Login to your cluster using oc login or exporting the KUBECONFIG
+oc login or set KUBECONFIG to the path to your kubeconfig file. For example export KUBECONFIG=~/my-ocp-env/auth/kubeconfig Check the values files before deployment You can run a check before deployment to make sure that you have the required variables to deploy the MLOps Fraud Detection Validated Pattern.
+You can run make predeploy to check your values. This will allow you to review your values and changed them in the case there are typos or old values. The values files that should be reviewed prior to deploying the MLOps Fraud Detection Validated Pattern are:
+Values File Description values-secret.yaml / values-secret-mlops-fraud-detection.yaml
+This is the values file that will include the rhpam and fhir-psql-db sections with all database et al secrets
+values-global.yaml
+File that is used to contain all the global values used by Helm
+Deploy Apply the changes to your cluster
+./pattern.sh make install If the install fails and you go back over the instructions and see what was missed and change it, then run make update to continue the installation.
+This takes some time. Especially for the OpenShift Data Foundation operator components to install and synchronize. The make install provides some progress updates during the install. It can take up to twenty minutes. Compare your make install run progress with the following video showing a successful install.
+Check that the operators have been installed in the UI.
+To verify, in the OpenShift Container Platform web console, navigate to Operators → Installed Operators page.
+Check that the Operator is installed in the openshift-operators namespace and its status is Succeeded.
+Using OpenShift GitOps to check on Application progress You can also check on the progress using OpenShift GitOps to check on the various applications deployed.
+Obtain the ArgoCD URLs and passwords.
+The URLs and login credentials for ArgoCD change depending on the pattern name and the site names they control. Follow the instructions below to find them, however you choose to deploy the pattern.
+Display the fully qualified domain names, and matching login credentials, for all ArgoCD instances:
+ARGO_CMD=\`oc get secrets -A -o jsonpath=&#39;{range .items[*]}{&#34;oc get -n &#34;}{.metadata.namespace}{&#34; routes; oc -n &#34;}{.metadata.namespace}{&#34; extract secrets/&#34;}{.metadata.name}{&#34; --to=-\\\\n&#34;}{end}&#39; | grep gitops-cluster\` CMD=\`echo $ARGO_CMD | sed &#39;s|- oc|-;oc|g&#39;\` eval $CMD The result should look something like:
+NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD hub-gitops-server hub-gitops-server-mlops-fraud-detection-hub.apps.mfd-cluster.aws.validatedpatterns.com hub-gitops-server https passthrough/Redirect None # admin.password xsyYU6eSWtwniEk1X3jL0c2TGfQgVpDH NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD cluster cluster-openshift-gitops.apps.mfd-cluster.aws.validatedpatterns.com cluster 8080 reencrypt/Allow None kam kam-openshift-gitops.apps.mfd-cluster.aws.validatedpatterns.com kam 8443 passthrough/None None openshift-gitops-server openshift-gitops-server-openshift-gitops.apps.mfd-cluster.aws.validatedpatterns.com openshift-gitops-server https passthrough/Redirect None # admin.password FdGgWHsBYkeqOczE3PuRpU1jLn7C2fD6 The most important ArgoCD instance to examine at this point is mlops-fraud-detection-hub. This is where all the applications for the pattern can be tracked.
+Check all applications are synchronised. There are thirteen different ArgoCD &#34;applications&#34; deployed as part of this pattern.
+Next Steps Run the demo.
+`,url:"https://validatedpatterns.io/patterns/mlops-fraud-detection/mfd-getting-started/",breadcrumb:"/patterns/mlops-fraud-detection/mfd-getting-started/"},"https://validatedpatterns.io/patterns/multicloud-gitops-amx-rhoai/mcg-amx-rhoai-getting-started/":{title:"Getting started",tags:[],content:` Deploying the Intel AMX accelerated Multicloud GitOps pattern with Openshift AI Prerequisites An OpenShift cluster
+To create an OpenShift cluster, go to the Red Hat Hybrid Cloud console and select Services -&gt; Containers -&gt; Create cluster.
+The cluster must have a dynamic StorageClass to provision PersistentVolumes.
+The cluster must have worker nodes with Intel AMX feature enabled, so the 5th Generation of Intel Xeon Processors is highly recommended
+Cluster sizing requirements.
+Optional: A second OpenShift cluster for multicloud demonstration.
+Install the tooling dependencies.
+The use of this pattern depends on having at least one running Red Hat OpenShift cluster. However, consider creating a cluster for deploying the GitOps management hub assets and a separate cluster for the managed cluster.
+If you do not have a running Red Hat OpenShift cluster, you can start one on a public or private cloud by using Red Hat Hybrid Cloud Console.
+Procedure Fork the amx-accelerated-rhoai-multicloud-gitops repository on GitHub.
+Clone the forked copy of this repository.
+git clone git@github.com:your-username/amx-accelerated-rhoai-multicloud-gitops.git Create a local copy of the secret values file that can safely include credentials for the config-demo application and edit it if you want to customize the secret. If not, the framework generates a random password.
+cp values-secret.yaml.template ~/values-secret-multicloud-gitops.yaml Do not commit this file. You do not want to push personal credentials to GitHub.
+(Optional) You may customize the deployment for your cluster depending on your needs by editing values-global.yaml and values-hub.yaml. To do this run the following commands:
+git checkout -b my-branch vi values-global.yaml git add values-global.yaml git commit values-global.yaml git push origin my-branch Deploy the pattern by running ./pattern.sh make install or by using the Validated Patterns Operator - both methods are described below.
+Deploying the cluster by using the pattern.sh file To deploy the cluster by using the pattern.sh file, complete the following steps:
+Login to your cluster by running the following command:
+oc login Optional: Set the KUBECONFIG variable for the kubeconfig file path:
+export KUBECONFIG=~/&lt;path_to_kubeconfig&gt; Deploy the pattern to your cluster. Run the following command:
+./pattern.sh make install Verify that the Operators have been installed.
+To verify, in the OpenShift Container Platform web console, navigate to Operators → Installed Operators page.
+Check that the following Operators are installed with Succeeded status (Figure 1):
+Advanced Cluster Management for Kubernetes
+multicluster engine for Kubernetes
+Node Feature Discovery Operator
+Red Hat Openshift GitOps
+Validated Patterns Operator
+OpenVINO Toolkit Operator
+Red Hat Openshift AI
+Figure 1. List of Installed Operators for AMX accelerated Multicloud GitOps with Openshift AI pattern Deploying the cluster by using the Validated Patterns Operator To install the Validated Patterns Operator:
+Log in to the Openshift Container Platform web console and select Operators &gt; OperatorHub.
+Search for Validated Patterns Operator, open it and click Install.
+Figure 2. Install Validated Patterns Operator step 1 Choose default settings for the installation mode, namespaces and update strategy and confirm it by clicking Install.
+Figure 3. Install Validated Patterns Operator step 2 Select Operators &gt; Installed Operators.
+Ensure that Validated Patterns Operator is listed in the openshift-operators project with a status Succeeded.
+Create Intel AMX accelerated Multicloud GitOps pattern with Openshift AI After a successful installation, open Validated Patterns Operator page. Next, go to Pattern tab and click Create Pattern.
+Set the Name field to multicloud-gitops-amx-rhoai and Cluster Group Name to hub, Values must be the same as in the values-global.yaml file (Figure 3).
+As a Git Config &gt; Target Repo value, paste the link to your fork. Under Git Config &gt; Target Revision write the name of your branch (Figure 3).
+Click Create button to create the pattern.
+Figure 4. Create Pattern Form Verify that the rest of Operators have been installed:
+To verify, in the OpenShift Container Platform web console, navigate to Operators → Installed Operators page.
+Check that the following Operators are installed with Succeeded status (Figure 1):
+Advanced Cluster Management for Kubernetes
+multicluster engine for Kubernetes
+Node Feature Discovery Operator
+Red Hat Openshift GitOps
+OpenVINO Toolkit Operator
+Red Hat Openshift AI
+Verification Go to the Hub ArgoCD and verify that all applications are synchronized. The URL can be found in Openshift Container Platform web console under Networking &gt; Routes for the project multicloud-gitops-amx-rhoai-hub or use command:
+oc -n multicloud-gitops-amx-rhoai-hub get route hub-gitops-server -ojsonpath=&#39;{.spec.host}&#39; All applications should be Healthy and Synced:
+Figure 5. ArgoCD panel with all applications As part of this pattern, HashiCorp Vault has been installed. Refer to the section on Vault.
+Start your workload Now, you are ready to use installed pattern.
+Test basic application deployment and setup with Hello World Demo.
+Jump straight to AI workload example with Intel AMX Demo.
+Next steps After the management hub is set up and works correctly, attach one or more managed clusters to the architecture.
+For instructions on deploying the edge, refer to Attach a managed cluster (edge) to the management hub.
+`,url:"https://validatedpatterns.io/patterns/multicloud-gitops-amx-rhoai/mcg-amx-rhoai-getting-started/",breadcrumb:"/patterns/multicloud-gitops-amx-rhoai/mcg-amx-rhoai-getting-started/"},"https://validatedpatterns.io/patterns/multicloud-gitops-amx/mcg-amx-getting-started/":{title:"Getting started",tags:[],content:` Deploying the Intel AMX accelerated Multicloud GitOps pattern Prerequisites An OpenShift cluster
+To create an OpenShift cluster, go to the Red Hat Hybrid Cloud console and select Services -&gt; Containers -&gt; Create cluster.
+The cluster must have a dynamic StorageClass to provision PersistentVolumes.
+Cluster sizing requirements.
+Optional: A second OpenShift cluster for multicloud demonstration.
+Install the tooling dependencies.
+The use of this pattern depends on having at least one running Red Hat OpenShift cluster. However, consider creating a cluster for deploying the GitOps management hub assets and a separate cluster for the managed cluster.
+If you do not have a running Red Hat OpenShift cluster, you can start one on a public or private cloud by using Red Hat Hybrid Cloud Console.
+Procedure Install the tooling dependencies.
+Fork the multicloud-gitops-amx repository on GitHub.
+Clone the forked copy of this repository.
+git clone git@github.com:your-username/amx-accelerated-multicloud-gitops.git Create a local copy of the secret values file that can safely include credentials for the config-demo application and edit it if you want to customize the secret. If not, the framework generates a random password.
+cp values-secret.yaml.template ~/values-secret-multicloud-gitops.yaml Do not commit this file. You do not want to push personal credentials to GitHub.
+(Optional) You may customize the deployment for your cluster depending on your needs by editing values-global.yaml and values-hub.yaml. To do this run the following commands:
+git checkout -b my-branch vi values-global.yaml git add values-global.yaml git commit values-global.yaml git push origin my-branch Deploy the pattern by running ./pattern.sh make install or by using the Validated Patterns Operator - both methods are described below.
+Deploying the cluster by using the pattern.sh file To deploy the cluster by using the pattern.sh file, complete the following steps:
+Login to your cluster by running the following command:
+oc login Optional: Set the KUBECONFIG variable for the kubeconfig file path:
+export KUBECONFIG=~/&lt;path_to_kubeconfig&gt; Deploy the pattern to your cluster. Run the following command:
+./pattern.sh make install Verify that the Operators have been installed.
+To verify, in the OpenShift Container Platform web console, navigate to Operators → Installed Operators page.
+Check that the following Operators are installed with Succeeded status (Figure 1):
+Advanced Cluster Management for Kubernetes
+multicluster engine for Kubernetes
+Node Feature Discovery Operator
+Red Hat Openshift GitOps
+Validated Patterns Operator
+Figure 1. List of Installed Operators for Multicloud GitOps Validated Pattern with AMX Deploying the cluster by using the Validated Patterns Operator To install the Validated Patterns Operator:
+Log in to the Openshift Container Platform web console and select Operators &gt; OperatorHub.
+Search for Validated Patterns Operator, open it and click Install.
+Figure 2. Install Validated Patterns Operator Choose default settings for the installation mode, namespaces and update strategy and confirm it by clicking Install.
+Select Operators &gt; Installed Operators.
+Ensure that Validated Patterns Operator is listed in the openshift-operators project with a status Succeeded.
+After succeeded installation open Validated Patterns Operator, go to Pattern tab and click Create Pattern.
+Fill the Name of the pattern multicloud-gitops-amx and Cluster Group Name hub (from values-global.yaml file).
+Under Git Config &gt; Target Repo copy the link to your fork and under Git Config &gt; Target Revision write the name of your branch (Figure 3).
+Click Create to create the pattern.
+Figure 3. Create Pattern Form Verify that the rest of Operators have been installed:
+To verify, in the OpenShift Container Platform web console, navigate to Operators → Installed Operators page.
+Check that the following Operators are installed with Succeeded status (Figure 1):
+Advanced Cluster Management for Kubernetes
+multicluster engine for Kubernetes
+Node Feature Discovery Operator
+Red Hat Openshift GitOps
+Add a secret for config-demo application (from values-secret-multicloud-gitops.yaml) to Vault manually:
+Go to Vault service route. URL can be found:
+by running command:
+oc -n vault get route vault -ojsonpath=&#39;{.spec.host}&#39; in Openshift Container Platform web console under Networking &gt; Routes for vault project.
+Log into the Vault using root token. Root token can be found by executing command:
+oc -n imperative get secrets vaultkeys -ojsonpath=&#39;{.data.vault_data_json}&#39; | base64 -d After login go to secret catalog and clik Create secret and fill all the fields manually (Figure 2):
+Path for this secret is global/config-demo (from values.yaml file for config-demo charts)
+Under Secret data key is secret (from values-secret-multicloud-gitops.yaml file) and in next field put its value.
+Click Add and then Save.
+Figure 4. Create secret Verification Go to the Hub ArgoCD and verify that all applications are synchronized. The URL can be found in Openshift Container Platform web console under Networking &gt; Routes for the project multicloud-gitops-amx-hub or use command:
+oc -n multicloud-gitops-amx-hub get route hub-gitops-server -ojsonpath=&#39;{.spec.host}&#39; All applications should be Healthy and Synced:
+Figure 5. ArgoCD panel with amx-app Check the logs of a pod amx-app to verify if it uses Intel AMX. In the OpenShift Container Platform web console, navigate to Workloads &gt; Pods. Change project to amx-app and open the Logs tab in the pod details. The appearance of avx_512_core_amx_bf16 flag on the list of compiled instructions confirms that Intel AMX is used.
+As part of this pattern, HashiCorp Vault has been installed. Refer to the section on Vault.
+Next steps After the management hub is set up and works correctly, attach one or more managed clusters to the architecture.
+For instructions on deploying the edge, refer to Attach a managed cluster (edge) to the management hub.
+`,url:"https://validatedpatterns.io/patterns/multicloud-gitops-amx/mcg-amx-getting-started/",breadcrumb:"/patterns/multicloud-gitops-amx/mcg-amx-getting-started/"},"https://validatedpatterns.io/patterns/multicloud-gitops-qat/mcg-qat-getting-started/":{title:"Getting started",tags:[],content:` Deploying the Intel QAT accelerated Multicloud GitOps pattern Prerequisites An OpenShift Container Platform cluster
+To create an OpenShift Container Platform cluster, go to the Red Hat Hybrid Cloud console and select Services -&gt; Containers -&gt; Create cluster.
+The cluster must have a dynamic StorageClass to provision PersistentVolumes. It was tested with ODF (OpenShift Data Foundation) or LVM Storage solutions. CephFS should be set as a default Storage Class - Setup Guide
+Cluster sizing requirements.
+OpenShift Container Platform Cluster must have Image Registry - Setup Guide
+BIOS should be configured according to official instructions. Please consult your platform guide on how to do this. Configuration options should be similar to these:
+Socket configuration &gt; IIO configuration &gt; Intel VT-d Enabled
+Platform Configuration &gt; Miscellaneous Configuration &gt; SR-IOV Support Enabled
+Socket Configuration &gt; IIO Configuration &gt; IOAT Configuration &gt; Sck&lt;n&gt; &gt; IOAT Configuration Enabled
+Optional: A second OpenShift Container Platform cluster for multicloud demonstration.
+Install the tooling dependencies.
+The use of this pattern depends on having at least one running Red Hat OpenShift Container Platform cluster. However, consider creating a cluster for deploying the GitOps management hub assets and a separate cluster for the managed cluster.
+If you do not have a running Red Hat OpenShift Container Platform cluster, you can start one on a public or private cloud by using Red Hat Hybrid Cloud Console.
+Procedure Fork the multicloud-gitops-qat repository on GitHub.
+Clone the forked copy of this repository.
+git clone git@github.com:your-username/qat-accelerated-istio.git Create a local copy of the secret values file that can safely include credentials for the config-demo application and edit it if you want to customize the secret. If not, the framework generates a random password.
+cp values-secret.yaml.template ~/values-secret-multicloud-gitops.yaml Do not commit this file. You do not want to push personal credentials to GitHub.
+(Optional) You may customize the deployment for your cluster depending on your needs by editing values-global.yaml and values-hub.yaml. To do this run the following commands:
+git checkout -b my-branch vi values-global.yaml git add values-global.yaml git commit values-global.yaml git push origin my-branch Deploy the pattern by running ./pattern.sh make install or by using the Validated Patterns Operator - both methods are described below.
+Deploying the cluster by using the pattern.sh file This is preferred way of installation, as it does not require from user to manually generate and put certificates in Hashicorp Vault. To deploy the cluster by using the pattern.sh file, complete the following steps:
+Login to your cluster by running the following command:
+oc login Optional: Set the KUBECONFIG variable for the kubeconfig file path:
+export KUBECONFIG=~/&lt;path_to_kubeconfig&gt; Deploy the pattern to your cluster. Script will automatically generate certificates and keys in /HOME/certs directory. Run the following command:
+./pattern.sh make install (Optional) If cluster is behind proxy extra settings might be needed for unsealing Vault. Please run the following command (put your proxy information in place of angle braced &lt;PLACEHOLDERS&gt;):
+oc -n imperative patch cj imperative-cronjob -p &#39;{&#34;spec&#34;:{&#34;jobTemplate&#34;:{&#34;spec&#34;:{&#34;template&#34;:{&#34;spec&#34;:{&#34;initContainers&#34;:[{&#34;name&#34;: &#34;git-init&#34;, &#34;env&#34;: [{&#34;name&#34;:&#34;HOME&#34;,&#34;value&#34;:&#34;/git/home&#34;},{&#34;name&#34;:&#34;HTTP_PROXY&#34;, &#34;value&#34;:&#34;&lt;PUT_YOUR_HTTP_PROXY_HERE&gt;&#34;},{&#34;name&#34;:&#34;HTTPS_PROXY&#34;,&#34;value&#34;:&#34;&lt;PUT_YOUR_HTTPS_PROXY_HERE&gt;&#34;},{&#34;name&#34;:&#34;NO_PROXY&#34;,&#34;value&#34;:&#34;&lt;PUT_YOUR_NOPROXY_HERE&gt;&#34;},{&#34;name&#34;:&#34;http_proxy&#34;, &#34;value&#34;:&#34;&lt;PUT_YOUR_HTTP_PROXY_HERE&gt;&#34;},{&#34;name&#34;:&#34;https_proxy&#34;,&#34;value&#34;:&#34;&lt;PUT_YOUR_HTTPS_PROXY_HERE&gt;&#34;},{&#34;name&#34;:&#34;no_proxy&#34;,&#34;value&#34;:&#34;&lt;PUT_YOUR_NOPROXY_HERE&gt;&#34;}]}]}}}}}}&#39; oc -n imperative patch cj unsealvault-cronjob -p &#39;{&#34;spec&#34;:{&#34;jobTemplate&#34;:{&#34;spec&#34;:{&#34;template&#34;:{&#34;spec&#34;:{&#34;initContainers&#34;:[{&#34;name&#34;: &#34;git-init&#34;, &#34;env&#34;: [{&#34;name&#34;:&#34;HOME&#34;,&#34;value&#34;:&#34;/git/home&#34;},{&#34;name&#34;:&#34;HTTP_PROXY&#34;, &#34;value&#34;:&#34;&lt;PUT_YOUR_HTTP_PROXY_HERE&gt;&#34;},{&#34;name&#34;:&#34;HTTPS_PROXY&#34;,&#34;value&#34;:&#34;&lt;PUT_YOUR_HTTPS_PROXY_HERE&gt;&#34;},{&#34;name&#34;:&#34;NO_PROXY&#34;,&#34;value&#34;:&#34;&lt;PUT_YOUR_NOPROXY_HERE&gt;&#34;},{&#34;name&#34;:&#34;http_proxy&#34;, &#34;value&#34;:&#34;&lt;PUT_YOUR_HTTP_PROXY_HERE&gt;&#34;},{&#34;name&#34;:&#34;https_proxy&#34;,&#34;value&#34;:&#34;&lt;PUT_YOUR_HTTPS_PROXY_HERE&gt;&#34;},{&#34;name&#34;:&#34;no_proxy&#34;,&#34;value&#34;:&#34;&lt;PUT_YOUR_NOPROXY_HERE&gt;&#34;}]}]}}}}}}&#39; After installation is done user must wait until all required Machine Configurations are applied to worker nodes. Depending on node specifications, rebooting and applying changes can take around 30 minutes. User can check progress by running command:
+oc get mcp If worker MachineConfigPool is marked as ready all applications will automatically continue deployment.
+Verify that the Operators have been installed.
+To verify, in the OpenShift Container Platform web console, navigate to Operators → Installed Operators page.
+Check that the following Operators are installed with Succeeded status (Figure 1):
+Advanced Cluster Management for Kubernetes
+multicluster engine for Kubernetes
+Node Feature Discovery Operator
+Red Hat Openshift GitOps
+Validated Patterns Operator
+Sail Operator
+Intel Device Plugin Operator
+Figure 1. List of Installed Operators for Multicloud GitOps Validated Pattern with qat Deploying the cluster by using the Validated Patterns Operator To install the Validated Patterns Operator:
+Log in to the OpenShift Container Platform web console and select Operators &gt; OperatorHub.
+Search for Validated Patterns Operator, open it and click Install.
+Figure 2. Install Validated Patterns Operator Choose default settings for the installation mode, namespaces and update strategy and confirm it by clicking Install.
+Select Operators &gt; Installed Operators.
+Ensure that Validated Patterns Operator is listed in the openshift-operators project with a status Succeeded.
+After succeeded installation open Validated Patterns Operator, go to Pattern tab and click Create Pattern.
+Set the Name field to multicloud-gitops-qat, and Cluster Group Name hub. Values must be the same as in values-global.yaml file (Figure 3).
+As a Git Config &gt; Target Repo value, paste the link to your fork. Under Git Config &gt; Target Revision write the name of your branch (Figure 3).
+Click the Create button to create the pattern.
+Figure 3. Create Pattern Form Verify that the rest of Operators have been installed:
+To verify, in the OpenShift Container Platform web console, navigate to Operators → Installed Operators page.
+Check that the following Operators are installed with Succeeded status (Figure 1):
+Advanced Cluster Management for Kubernetes
+multicluster engine for Kubernetes
+Node Feature Discovery Operator
+Red Hat Openshift GitOps
+Sail Operator
+Intel Device Plugin Operator
+Generate client and server certificates. You can refer to Istio official guide: https://istio.io/latest/docs/tasks/traffic-management/ingress/secure-ingress/#generate-client-and-server-certificates-and-keys
+After generating certificates, add them as secrets to Vault manually:
+Go to the Vault service route. The URL can be found either:
+by running following command:
+oc -n vault get route vault -ojsonpath=&#39;{.spec.host}&#39; or in the OpenShift Container Platform web console under Networking &gt; Routes for vault project.
+Log into the Vault using root token. Root token can be found by executing command:
+oc -n imperative get secrets vaultkeys -ojsonpath=&#39;{.data.vault_data_json}&#39; | base64 -d After logging in, go to secret catalog and click the Create secret button. You should see form with inputs, which must be filled manually (Figure 4).
+Path for this secrets should be filled with one of the following strings: global/certs/httpbin.example.com.crt, global/certs/example.com.crt, global/certs/httpbin.example.com.key.
+In the Secret data section add a new secret. In the left field (key) put the content string. On the right, paste your certificate.
+Click the Add button, and then the Save button.
+Figure 4. Create secret in the Vault Verification Go to the Hub ArgoCD and verify that all applications are synchronized. The URL can be found in OpenShift Container Platform web console under Networking &gt; Routes for the project multicloud-gitops-qat-hub or use command:
+oc -n multicloud-gitops-qat-hub get route hub-gitops-server -ojsonpath=&#39;{.spec.host}&#39; All applications should be Healthy and Synced:
+Figure 5. ArgoCD panel with qat-app Check the httpbin pod logs of an httpbin Deployment to verify if it uses Intel QAT. In the OpenShift Container Platform web console, navigate to Workloads &gt; Pods. Change project to httpbin and open the Logs tab in the pod details. Go to container istio-proxy and check if there are no errors.
+In case of Intel Device Plugin Operator not working correctly or if QAT is not available the error can look like this:
+No devices found No device found Failed to start QAT device. In case of wrong Security Context Constraints (SCC) the error can look like this:
+Cannot open /dev/vfio Verify that all certificates and keys were correctly generated in path /HOME_PATH/certs. There should be 11 files: client.example.com.crt, client.example.com.key, example.com.key, helloworld.example.com.csr, httpbin.example.com.crt, httpbin.example.com.key, client.example.com.csr, example.com.crt, helloworld.example.com.crt, helloworld.example.com.key, httpbin.example.com.csr.
+When everything is ready, you can check if Istio handles requests correctly by sending a request to the httpbin application. Note that &lt;NODE_IP&gt; value can be IP address of any worker node.
+export INGRESS_HOST=&lt;NODE_IP&gt; export INGRESS_NS=istio-system export INGRESS_NAME=istio-ingressgateway export SECURE_INGRESS_PORT=$(oc -n &#34;\${INGRESS_NS}&#34; get service &#34;\${INGRESS_NAME}&#34; -o jsonpath=&#39;{.spec.ports[?(@.name==&#34;https&#34;)].nodePort}&#39;) cd $HOME curl --resolve &#34;httpbin.example.com:\${SECURE_INGRESS_PORT}:$INGRESS_HOST&#34; --cacert certs/httpbin.example.com.crt &#34;https://httpbin.example.com:\${SECURE_INGRESS_PORT}/status/418&#34; User should get following response:
+-=[ teapot ]=- _...._ .&#39; _ _ \`. | .&#34;\` ^ \`&#34;. _, \\_;\`&#34;---&#34;\`|// | ;/ \\_ _/ \`&#34;&#34;&#34;\` As a part of this pattern, HashiCorp Vault has been installed. Refer to the section on Vault.
+Next steps After the management hub is set up and works correctly, attach one or more managed clusters to the architecture.
+For instructions on deploying the edge, refer to Attach a managed cluster (edge) to the management hub.
+`,url:"https://validatedpatterns.io/patterns/multicloud-gitops-qat/mcg-qat-getting-started/",breadcrumb:"/patterns/multicloud-gitops-qat/mcg-qat-getting-started/"},"https://validatedpatterns.io/patterns/multicloud-gitops-sgx-hello-world/mcg-sgx-hello-world-getting-started/":{title:"Getting started",tags:[],content:` Deploying the Intel SGX protected application in Multicloud GitOps pattern Prerequisites An OpenShift cluster
+To create an OpenShift cluster, go to the Red Hat Hybrid Cloud console and select Services -&gt; Containers -&gt; Create cluster.
+The cluster must have a dynamic StorageClass to provision PersistentVolumes.
+Cluster sizing requirements.
+Intel SGX must be enabled in BIOS (Basic Input Output System) on at least one worker machines - specific steps depends on platform.
+Install the tooling dependencies.
+Optional: Machine with the Ubuntu 22.04 (for image conversion purposes - doesn’t need to have SGX feature enabled) and git.
+Gramine Shielded Containers (GSC) application requires a machine with the same OS as an input image which will be conversed.
+Install the GSC prerequisites.
+Optional: A second OpenShift cluster for multicloud demonstration.
+The use of this pattern depends on having at least one running Red Hat OpenShift cluster. However, consider creating a cluster for deploying the GitOps management hub assets and a separate cluster for the managed cluster.
+If you do not have a running Red Hat OpenShift cluster, you can start one on a public or private cloud by using Red Hat Hybrid Cloud Console.
+Procedure Fork the multicloud-gitops-sgx-hello-world repository on GitHub.
+Clone the forked copy of this repository.
+git clone git@github.com:your-username/multicloud-gitops-sgx-hello-world.git Create a local copy of the secret values file that can safely include credentials for the config-demo application and edit it if you want to customize the secret. If not, the framework generates a random password.
+cp values-secret.yaml.template ~/values-secret-multicloud-gitops.yaml Do not commit this file. You do not want to push personal credentials to GitHub.
+(Optional) You may customize the deployment for your cluster depending on your needs by editing values-global.yaml and values-hub.yaml. To do this run the following commands:
+git checkout -b my-branch vi values-global.yaml git add values-global.yaml git commit values-global.yaml git push origin my-branch (Optional) Prepare and build hello-world docker image and convert it to secure version using GSC - described below. The sample image is available on Red Hat container registry (quay.io/hybridcloudpatterns/hello-world-sgx:3.12) and is pulled automatically during pattern installation process with default variables.
+Deploy the pattern by running ./pattern.sh make install or by using the Validated Patterns Operator - both methods are described below.
+Optional: Prepare docker image and convert it to use Intel SGX To build docker image and convert it to secure version with SGX, complete the following steps using machine dedicated for GSC conversion:
+Create an empty file named Dockerfile:
+$ touch Dockerfile Using a text editor, copy the following contents to the Dockerfile:
+FROM python:3.12 RUN apt update RUN rm /usr/bin/X11 ENTRYPOINT [&#34;python3&#34;, &#34;-c&#34;, &#34;print(&#39;HelloWorld!&#39;)&#34;] Build the docker image using the following command:
+$ docker build -t hello-world . Clone GSC repo:
+$ git clone https://github.com/gramineproject/gsc.git Copy configuration file from sample template:
+$ cd gsc $ cp config.yaml.template config.yaml (Optional) This file can be adjusted if needed.
+Create a new hello-world.manifest file containing parameters of conversion:
+loader.pal_internal_mem_size = &#34;1G&#34; sgx.enclave_size = &#34;1G&#34; sgx.thread_num = 1024 Generate the signing key:
+$ openssl genrsa -3 -out enclave-key.pem 3072 Build secure image using gsc command:
+$ ./gsc build hello-world hello-world.manifest Sign the graminized docker image:
+$ ./gsc sign-image hello-world enclave-key.pem Push secured container image to the registry which is available on the cluster:
+Tag secured container image with appropriate tag and push it to the registry:
+$ docker tag gsc-hello-world &lt;DOCKER_REPOSITORY&gt;:&lt;TAG&gt; &lt;DOCKER_REPOSITORY&gt; is name a docker repository, &lt;TAG&gt; is a version of an image
+Login to Docker Hub:
+$ docker login -u=&lt;DOCKER_ID&gt; docker.io &lt;DOCKER_ID&gt; is your login to Docker Hub
+Push the image to registry:
+$ docker push &lt;DOCKER_REPOSITORY&gt;:&lt;TAG&gt; Update the file charts/all/hello-world-sgx/values.yaml with the information about your image in your forked repo with pattern.
+Deploying the cluster by using the pattern.sh file To deploy the cluster by using the pattern.sh file, complete the following steps:
+Login to your cluster by running the following command:
+oc login Optional: Set the KUBECONFIG variable for the kubeconfig file path:
+export KUBECONFIG=~/&lt;path_to_kubeconfig&gt; Deploy the pattern to your cluster. Run the following command:
+./pattern.sh make install Verify that the Operators have been installed.
+To verify, in the OpenShift Container Platform web console, navigate to Operators → Installed Operators page.
+Check that the following Operators are installed with Succeeded status (Figure 1):
+Advanced Cluster Management for Kubernetes
+Intel Device Plugins Operator
+multicluster engine for Kubernetes
+Node Feature Discovery Operator
+Red Hat Openshift GitOps
+Validated Patterns Operator
+Figure 1. List of Installed Operators for Multicloud GitOps Validated Pattern with SGX Deploying the cluster by using the Validated Patterns Operator To install the Validated Patterns Operator:
+Log in to the Openshift Container Platform web console and select Operators &gt; OperatorHub.
+Search for Validated Patterns Operator, open it and click Install.
+Figure 2. Install Validated Patterns Operator Choose default settings for the installation mode, namespaces and update strategy and confirm it by clicking Install.
+Select Operators &gt; Installed Operators.
+Ensure that Validated Patterns Operator is listed in the openshift-operators project with a status Succeeded.
+After a successful installation open the Validated Patterns Operator page. Next, go to Pattern tab and click Create Pattern.
+Set the Name field to multicloud-gitops-sgx-hello-world, and the Cluster Group Name to hub. Values must be the same as in the values-global.yaml file (Figure 3).
+As a Git Config &gt; Target Repo value, paste the link to your fork. Under Git Config &gt; Target Revision write the name of your branch (Figure 3).
+Click the Create button to create the pattern.
+Figure 3. Create Pattern Form Verify that the rest of Operators have been installed:
+To verify, in the OpenShift Container Platform web console, navigate to Operators → Installed Operators page.
+Check that the following Operators are installed with Succeeded status (Figure 1):
+Advanced Cluster Management for Kubernetes
+Intel Device Plugins Operator
+multicluster engine for Kubernetes
+Node Feature Discovery Operator
+Red Hat Openshift GitOps
+Add a secret for config-demo application (from values-secret-multicloud-gitops.yaml) to Vault manually:
+Go to Vault service route. URL can be found:
+by running command:
+oc -n vault get route vault -ojsonpath=&#39;{.spec.host}&#39; in Openshift Container Platform web console under Networking &gt; Routes for vault project.
+Log into the Vault using root token. Root token can be found by executing command:
+oc -n imperative get secrets vaultkeys -ojsonpath=&#39;{.data.vault_data_json}&#39; | base64 -d After login go to secret catalog and clik Create secret and fill all the fields manually (Figure 4):
+Put global/config-demo value in the Path for this secret field (the value comes from values-secret-multicloud-gitops.yaml file).
+Add one Secret data key-value pair. Put secret as a key (left field). Click Add button to confirm.
+Click Save to save changes.
+Figure 4. Create secret Verification Go to the Hub ArgoCD and verify that all applications are synchronized. The URL can be found in Openshift Container Platform web console under Networking &gt; Routes for the project multicloud-gitops-sgx-hello-world-hub or use command:
+oc -n multicloud-gitops-sgx-hello-world-hub get route hub-gitops-server -ojsonpath=&#39;{.spec.host}&#39; All applications should be Healthy and Synced:
+Figure 5. ArgoCD panel with hello-world-sgx app Check the logs of a pod hello-world-sgx to verify if it uses Intel SGX. In the OpenShift Container Platform web console, navigate to Workloads &gt; Pods. Change project to hello-world-sgx and open the Logs tab in the pod details. The Gramine output confirms that Intel SGX is used.
+In case of pod hello-world-sgx crashing, delete it manually to be recreated - not restarted.
+As part of this pattern, HashiCorp Vault has been installed. Refer to the section on Vault.
+Next steps After the management hub is set up and works correctly, attach one or more managed clusters to the architecture.
+For instructions on deploying the edge, refer to Attach a managed cluster (edge) to the management hub.
+`,url:"https://validatedpatterns.io/patterns/multicloud-gitops-sgx-hello-world/mcg-sgx-hello-world-getting-started/",breadcrumb:"/patterns/multicloud-gitops-sgx-hello-world/mcg-sgx-hello-world-getting-started/"},"https://validatedpatterns.io/patterns/multicloud-gitops-sgx/mcg-sgx-getting-started/":{title:"Getting started",tags:[],content:` Deploying the Intel SGX protected Vault for Multicloud GitOps pattern Prerequisites An OpenShift cluster
+To create an OpenShift cluster, go to the Red Hat Hybrid Cloud console and select Services -&gt; Containers -&gt; Create cluster.
+The cluster must have a dynamic StorageClass to provision PersistentVolumes. It was tested with ODF (OpenShift Data Foundation) or LVM Storage solutions. Remember, to mark chosen storage class as default in OpenShift to automatically pick up by the pattern.
+Cluster sizing requirements.
+The cluster has got at least one worker machine with Intel SGX enabled in BIOS.
+Optional: A second OpenShift cluster for multicloud demonstration.
+Install the tooling dependencies.
+The use of this pattern depends on having at least one running Red Hat OpenShift cluster. However, consider creating a cluster for deploying the GitOps management hub assets and a separate cluster for the managed cluster.
+If you do not have a running Red Hat OpenShift cluster, you can start one on a public or private cloud by using Red Hat Hybrid Cloud Console.
+Procedure Enable Intel SGX in BIOS. Depending on your platform, the enablement of Intel SGX might vary. Below are steps for enablement on &#34;Quanta Cloud Technology&#34; D54Q-2U platform based on 5th Generation Intel Xeon:
+Socket Configuration -&gt; Memory Configuration -&gt; Memory Map -&gt; 1LM Socket Configuration -&gt; Processor Configuration -&gt; Memory Encryption (TME) -&gt; Enabled Socket Configuration -&gt; Processor Configuration -&gt; Total Memory Encryption (TME) Bypass -&gt; Disabled Socket Configuration -&gt; Processor Configuration -&gt; Total Memory Encryption Multi-Tenant(TME-MT) -&gt; Enabled Socket Configuration -&gt; Processor Configuration -&gt; SW Guard Extensions (SGX) -&gt; Enabled Socket Configuration -&gt; Processor Configuration -&gt; PRM Size for SGX -&gt; MAX or whatever size needed &lt;SGX_MEMORY_SIZE&gt; is SGX reserved memory, make sure that at least 1GB of RAM is allocated. In the sample settings, a higher value was allocated but this needs to be adjusted to your platform. If you have a different platform, refer to your motherboard or server documentation for Intel SGX enablement instructions.
+Install the tooling dependencies.
+Fork the sgx-multicloud-gitops-vault repository on GitHub.
+Clone the forked copy of this repository.
+git clone git@github.com:your-username/sgx-multicloud-gitops-vault.git Create a local copy of the secret values file that can safely include credentials for the config-demo application and edit it if you want to customize the secret. If not, the framework generates a random password.
+cp values-secret.yaml.template ~/values-secret-multicloud-gitops.yaml Do not commit this file. You do not want to push personal credentials to GitHub.
+(Optional) You may customize the deployment for your cluster depending on your needs by editing values-global.yaml and values-hub.yaml. To do this run the following commands:
+git checkout -b my-branch vi values-global.yaml git add values-global.yaml git commit values-global.yaml git push origin my-branch (Optional) The SGX-protected Vault container image is available as a pre-built image and currently, the pattern is configured to use as is. When there is a need to build it on your own and protect it with SGX, then follow the description below.
+Deploy the pattern by running ./pattern.sh make install or by using the Validated Patterns Operator - both methods are described below.
+(Optional) Prepare Vault docker image and convert to SGX Pre-built protected Vault image is available to pull from quay.io/hybridcloudpatterns/sgx-protected-vault. If a user would like to build such an image on their own, there are step-by-step instructions below.
+Prerequisites: Gramine Shielded Containers application requires a machine with the same OS as the input image to create an SGX converted image. In this case, it would be Red Hat Enterprise Linux 8.8. This machine does not have to have the SGX feature enabled because it will be used for conversion purposes only.
+RedHat portal account. This is necessary to pull the input Vault container image.
+Container registry account available to store SGX-protected Vault image. Such a registry has to be externally available; so that the OpenShift cluster could access it. Also, the registry can be public, so that the OpenShift cluster can pull the image without extra credentials. Otherwise storing container registry credentials has to be implemented.
+Procedure Create a modified Vault docker file which will be input for the SGX conversion process: First, create a new directory and change it:
+mkdir vault cd vault Create the Dockerfile with the below content:
+FROM registry.connect.redhat.com/hashicorp/vault:1.15.3-ubi ENTRYPOINT [&#34;vault&#34;, &#34;server&#34;, &#34;-config=/vault/config/extraconfig-from-values.hcl&#34;] Login to the RedHat container image repository using docker:
+docker login registry.connect.redhat.com The user will be asked to enter credentials for the RedHat account. Start building process:
+docker build -t vault-without-sgx . Install Gramine Shielded Containers prerequisites according to GSC documentation
+Clone GSC repo:
+git clone https://github.com/gramineproject/gsc.git Change directory to newly created GSC repository:
+cd gsc Copy config file from sample template provided with GSC:
+cp config.yaml.template config.yaml This config file can be adjusted as needed.+ Sample config below:
+# Specify the OS distro that is used to build Gramine, i.e., the distro from where the Gramine build # gets all tools and dependencies from. This distro should match the distro underlying the # application&#39;s Docker image; otherwise the results may be unpredictable (if you specify \`&#34;auto&#34;\`, # which is recommended, you don&#39;t need to worry about the mismatch). # # Currently supported distros are: # - ubuntu:20.04, ubuntu:21.04, ubuntu:22.04, ubuntu:23.04 # - debian:10, debian:11, debian:12 # - centos:8 # - redhat/ubi8:8.8 # - redhat/ubi8-minimal:8.8 # If Distro is set to &#34;auto&#34;, GSC detects the distro automatically by examining the supplied # Docker image. Alternatively, Distro can be set to one of the supported distros mentioned above. Distro: &#34;auto&#34; # If the image has a specific registry, define it here. # Empty by default; example value: &#34;registry.access.redhat.com/ubi8&#34;. Registry: &#34;&#34; # If you&#39;re using your own fork and branch of Gramine, specify the GitHub link and the branch name # below; typically, you want to keep the default values though. # # It is also possible to specify the prebuilt Gramine Docker image (that was built previously via # the \`gsc build-gramine\` command). For this, remove Repository and Branch and instead write: # Image: &#34;&lt;prebuilt Gramine Docker image&gt;&#34; # # GSC releases are guaranteed to work with corresponding Gramine releases (and GSC \`master\` # branch is guaranteed to work with current Gramine \`master\` branch). Gramine: Repository: &#34;https://github.com/gramineproject/gramine.git&#34; Branch: &#34;master&#34; # Specify the Intel SGX driver installed on your machine (more specifically, on the machine where # the graminized Docker container will run); there are several variants of the SGX driver: # # - upstream (in-kernel) driver: use empty values like below # Repository: &#34;&#34; # Branch: &#34;&#34; # # - DCAP out-of-tree driver: same as above, use empty values # Repository: &#34;&#34; # Branch: &#34;&#34; # # - legacy out-of-tree driver: use something like the below values, but adjust the branch name # Repository: &#34;https://github.com/01org/linux-sgx-driver.git&#34; # Branch: &#34;sgx_driver_1.9&#34; # SGXDriver: Repository: &#34;&#34; Branch: &#34;&#34; Create vault.manifest file which contains the conversion configuration:
+sgx.enclave_size = &#34;2G&#34; sgx.max_threads = 512 sgx.allowed_files = [ &#34;file:/vault/&#34;, ] sgx.trusted_files = [ &#34;file:/home/vault/&#34;, &#34;file:/etc/security/pam_env.conf&#34;, &#34;file:/etc/security/limits.conf&#34;, &#34;file:/var/log/lastlog&#34;, ] loader.uid = 100 loader.gid = 107 fs.mounts = [ { path = &#34;/vault/data&#34;, uri = &#34;file:/vault/data&#34;, type = &#34;chroot&#34; }, ] loader.env.HOME = { passthrough = true } loader.env.HOST_IP = { passthrough = true } loader.env.HOSTNAME = { passthrough = true } loader.env.POD_IP = { passthrough = true } loader.env.SKIP_CHOWN = { passthrough = true } loader.env.SKIP_SETCAP = { passthrough = true } loader.env.VAULT_ADDR = { passthrough = true } loader.env.VAULT_API_ADDR = { passthrough = true } loader.env.VAULT_CACERT = { passthrough = true } loader.env.VAULT_CLUSTER_ADDR = { passthrough = true } loader.env.VAULT_K8S_NAMESPACE = { passthrough = true } loader.env.VAULT_K8S_POD_NAME = { passthrough = true } Generate the signing key:
+openssl genrsa -3 -out enclave-key.pem 3072 Build a protected image using the gsc command:
+./gsc build vault-without-sgx vault.manifest Sign the graminized docker image:
+./gsc sign-image vault-without-sgx enclave-key.pem (Optional) Log in to an image registry server (if the registry requires it):
+docker login -u=&lt;USER_NAME&gt; docker.io &lt;USER_NAME&gt; is the name of a user, which will be used to log in to the image registry server
+Tag protected container image with appropriate tag:
+docker tag gsc-vault-without-sgx &lt;DESTINATION_IMAGE_NAME&gt; &lt;DESTINATION_IMAGE_NAME&gt; is the name of the image in a registry
+Push protected container image to a registry:
+docker push &lt;DESTINATION_IMAGE_NAME&gt; replace &lt;DESTINATION_IMAGE_NAME&gt; with proper name
+Deploying the cluster by using the pattern.sh file To deploy the cluster by using the pattern.sh file, complete the following steps:
+Log in to your cluster by running the following command:
+oc login Optional: Set the KUBECONFIG variable for the kubeconfig file path:
+export KUBECONFIG=~/&lt;path_to_kubeconfig&gt; Deploy the pattern to your cluster. Run the following command:
+./pattern.sh make install Verify that the Operators have been installed.
+To verify, in the OpenShift Container Platform web console, navigate to Operators → Installed Operators page.
+Check that the following Operators are installed with Succeeded status (Figure 1):
+Advanced Cluster Management for Kubernetes
+Intel Device Plugins Operator
+multicluster engine for Kubernetes
+Node Feature Discovery Operator
+Red Hat Openshift GitOps
+Validated Patterns Operator
+Figure 1. List of Installed Operators for Multicloud GitOps Validated Pattern with SGX Deploying the cluster by using the Validated Patterns Operator To install the Validated Patterns Operator:
+Log in to the Openshift Container Platform web console and select Operators &gt; OperatorHub.
+Search for Validated Patterns Operator, open it and click Install.
+Figure 2. Install Validated Patterns Operator Choose default settings for the installation mode, namespaces and update strategy and confirm it by clicking Install.
+Select Operators &gt; Installed Operators.
+Ensure that Validated Patterns Operator is listed in the openshift-operators project with a status Succeeded.
+After a successful installation, open the Validated Patterns Operator page. Next, go to the Pattern tab and click Create Pattern.
+Set the Name field to multicloud-gitops-sgx, and the Cluster Group Name to hub. Values must be the same as in the values-global.yaml file (Figure 3).
+As a Git Config &gt; Target Repo value, paste the link to your fork. Under Git Config &gt; Target Revision write the name of your branch (Figure 3).
+Click the Create button to create the pattern.
+Figure 3. Create Pattern Form Verify that the rest of Operators have been installed:
+To verify, in the OpenShift Container Platform web console, navigate to Operators → Installed Operators page.
+Check that the following Operators are installed with Succeeded status (Figure 1):
+Advanced Cluster Management for Kubernetes
+Intel Device Plugins Operator
+multicluster engine for Kubernetes
+Node Feature Discovery Operator
+Red Hat Openshift GitOps
+Add a secret for config-demo application (from values-secret-multicloud-gitops.yaml) to Vault manually:
+Go to the Vault service route. URL can be found:
+by running the command:
+oc -n vault get route vault -ojsonpath=&#39;{.spec.host}&#39; in Openshift Container Platform web console under Networking &gt; Routes for vault project.
+Log into the Vault using the root token. Root token can be found by executing the command:
+oc -n imperative get secrets vaultkeys -ojsonpath=&#39;{.data.vault_data_json}&#39; | base64 -d After login go to secret catalog click Create secret and fill in all the fields manually (Figure 2):
+Path for this secret is global/config-demo (from values.yaml file for config-demo charts)
+Under Secret data key is secret (from values-secret-multicloud-gitops.yaml file) and in the next field put its value.
+Click Add and then Save.
+Figure 4. Create secret Verification Go to the Hub ArgoCD and verify that all applications are synchronized. The URL can be found in Openshift Container Platform web console under Networking &gt; Routes for the project vault or use the command:
+oc -n vault get route vault -ojsonpath=&#39;{.spec.host}&#39; All applications should be Healthy and Synced:
+Figure 5. ArgoCD panel with sgx-app Check the logs of a pod vault-0 to verify if it contains Gramine header. In the OpenShift Container Platform web console, navigate to Workloads &gt; Pods. Change the project to vault and open the Logs tab in the pod details. The appearance of Gramine is starting header confirms that Intel SGX is used.
+Next steps After the management hub is set up and works correctly, attach one or more managed clusters to the architecture.
+For instructions on deploying the edge, refer to Attach a managed cluster (edge) to the management hub.
+`,url:"https://validatedpatterns.io/patterns/multicloud-gitops-sgx/mcg-sgx-getting-started/",breadcrumb:"/patterns/multicloud-gitops-sgx/mcg-sgx-getting-started/"},"https://validatedpatterns.io/patterns/multicloud-gitops/mcg-getting-started/":{title:"Getting started",tags:[],content:` Deploying the Multicloud GitOps pattern Prerequisites An OpenShift cluster
+To create an OpenShift cluster, go to the Red Hat Hybrid Cloud console.
+Select Services -&gt; Containers -&gt; Create cluster.
+The cluster must have a dynamic StorageClass to provision PersistentVolumes. See sizing your cluster.
+Optional: A second OpenShift cluster for multicloud demonstration.
+Install the tooling dependencies.
+The use of this pattern depends on having at least one running Red Hat OpenShift cluster. However, consider creating a cluster for deploying the GitOps management hub assets and a separate cluster for the managed cluster.
+If you do not have a running Red Hat OpenShift cluster, you can start one on a public or private cloud by using Red Hat Hybrid Cloud Console.
+Procedure Fork the multicloud-gitops repository on GitHub.
+Clone the forked copy of this repository.
+git clone git@github.com:your-username/multicloud-gitops.git Create a local copy of the secret values file that can safely include credentials. Run the following commands:
+cp values-secret.yaml.template ~/values-secret-multicloud-gitops.yaml vi ~/values-secret-multicloud-gitops.yaml Do not commit this file. You do not want to push personal credentials to GitHub. If you do not want to customize the secrets, these steps are not needed. The framework generates a random password for the config-demo application.
+Customize the deployment for your cluster. Run the following command:
+git checkout -b my-branch vi values-global.yaml git add values-global.yaml git commit values-global.yaml git push origin my-branch Deploy the pattern by running ./pattern.sh make install or by using the Validated Patterns Operator.
+Deploying the cluster by using the pattern.sh file To deploy the cluster by using the pattern.sh file, complete the following steps:
+Login to your cluster by running the following command:
+oc login Optional: Set the KUBECONFIG variable for the kubeconfig file path:
+export KUBECONFIG=~/&lt;path_to_kubeconfig&gt; Deploy the pattern to your cluster. Run the following command:
+./pattern.sh make install Verify that the Operators have been installed.
+To verify, in the OpenShift Container Platform web console, navigate to Operators → Installed Operators page.
+Check that the Operator is installed in the openshift-operators namespace and its status is Succeeded.
+Verify that all applications are synchronized. Under the project multicloud-gitops-hub click the URL for the hub gitops server. The Vault application is not synched.
+As part of this pattern, HashiCorp Vault has been installed. Refer to the section on Vault.
+Next steps After the management hub is set up and works correctly, attach one or more managed clusters to the architecture.
+For instructions on deploying the edge, refer to Attach a managed cluster (edge) to the management hub.
+`,url:"https://validatedpatterns.io/patterns/multicloud-gitops/mcg-getting-started/",breadcrumb:"/patterns/multicloud-gitops/mcg-getting-started/"},"https://validatedpatterns.io/patterns/ansible-edge-gitops-kasten/getting-started/":{title:"Getting Started",tags:[],content:`Deploying the Ansible Edge GitOps Pattern General Prerequisites An OpenShift cluster ( Go to the OpenShift console). See also sizing your cluster. Currently this pattern only supports AWS. It could also run on a baremetal OpenShift cluster, because OpenShift Virtualization supports that; there would need to be some customizations made to support it as the default is AWS. We hope that GCP and Azure will support provisioning metal workers in due course so this can be a more clearly multicloud pattern. A GitHub account (and, optionally, a token for it with repositories permissions, to read from and write to your forks) The helm binary, see here Ansible, which is used in the bootstrap and provisioning phases of the pattern install (and to configure Ansible Automation Platform). Please note that when run on AWS, this pattern will provision an additional worker node, which will be a metal instance (c5n.metal) to run the Edge Virtual Machines. This worker is provisioned through the OpenShift MachineAPI and will be automatically cleaned up when the cluster is destroyed. The use of this pattern depends on having a running Red Hat OpenShift cluster. It is desirable to have a cluster for deploying the GitOps management hub assets and a separate cluster(s) for the managed cluster(s).
+If you do not have a running Red Hat OpenShift cluster you can start one on a public or private cloud by using Red Hat&rsquo;s cloud service.
+Credentials Required in Pattern In addition to the OpenShift cluster, you will need to prepare a number of secrets, or credentials, which will be used in the pattern in various ways. To do this, copy the values-secret.yaml template to your home directory as values-secret.yaml and replace the explanatory text as follows:
+AWS Credentials (an access key and a secret key). These are used to provision the metal worker in AWS (which hosts the VMs) and to access a pre-created S3 bucket for exporting VM backups with Veeam Kasten. --- # NEVER COMMIT THESE VALUES TO GIT version: &#34;2.0&#34; secrets: - name: aws-creds fields: - name: aws_access_key_id value: &#39;An aws access key that can provision EC2 VMs and read/write to S3&#39; - name: aws_secret_access_key value: &#39;An aws access secret key that can provision VMs and read/write to S3&#39; A username and SSH Keypair (private key and public key). These will be used to provide access to the Kiosk VMs in the demo. - name: kiosk-ssh fields: # Username of user to which the privatekey and publickey are attached - cloud-user is a typical value - name: username value: &#39;cloud-user&#39; # Private ssh key of the user who will be able to elevate to root to provision kiosks - name: privatekey value: | -----BEGIN OPENSSH PRIVATE KEY----- b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAACFwAAAAdzc2gtcn ... 5nZRiM0qkhEAAAAKY2xvdWQtdXNlcgE= -----END OPENSSH PRIVATE KEY----- # Public ssh key of the user who will be able to elevate to root to provision kiosks - name: publickey value: | ssh-rsa AAAAB3NzaC1yc2EAAAA...xiVgKANw== cloud-user A Red Hat Subscription Management username and password. These will be used to register Kiosk VM templates to the Red Hat Content Delivery Network and install content on the Kiosk VMs to run the demo. - name: rhsm fields: - name: username value: &#39;username of user to register RHEL VMs&#39; - name: password value: &#39;password of rhsm user in plaintext&#39; Container &ldquo;extra&rdquo; arguments which will set the admin password for the ignition application when it&rsquo;s running. - name: kiosk-extra fields: # Optional extra params to pass to kiosk ignition container, including admin password - name: container_extra_params value: &#39;--privileged -e GATEWAY_ADMIN_PASSWORD=redhat&#39; A userData block to use with cloud-init. This will allow console login as the user you specify (traditionally cloud-user) with the password you specify. The value in cloud-init is used as the default; roles in the edge-gitops-vms chart can also specify other secrets to use by referencing them in the role block. - name: cloud-init fields: - name: userData value: |- #cloud-config user: &#39;username of user for console, probably cloud-user&#39; password: &#39;a suitable password to use on the console&#39; chpasswd: { expire: False } A manifest file with an entitlement to run Ansible Automation Platform. This file (which will be a .zip file) will be posted to to Ansible Automation Platform instance to enable its use. Instructions for creating a manifest file can be found here - name: aap-manifest fields: - name: b64content # Ex. /Users/john.doe/ansible-edge-gitops-kasten/my-aap-manifest.zip path: &#39;full path and file name of the Satellite Manifest .zip for entitling Ansible Automation Platform&#39; base64: true A passphrase that will be used to encrypt backups of the Veeam Kasten internal catalog of restore points, a process known as Kasten DR. These Kasten DR backups can be used to restore access to the catalog of previously created application backups in the event of infrastructure failure or cluster loss. - name: kastendr-passphrase fields: - name: key value: &#39;passphrase&#39; Prerequisites for deployment via make install If you are going to install via make install from your workstation, you will need the following tools and packages:
+{% include prerequisite-tools.md %}
+And additionally, the following ansible collections:
+community.okd redhat_cop.controller_configuration awx.awx To see what collections are installed:
+ansible-galaxy collection list
+To install a collection that is not currently installed:
+ansible-galaxy collection install &lt;collection&gt;
+How to deploy Login to your cluster using oc login or exporting the KUBECONFIG
+oc login or set KUBECONFIG to the path to your kubeconfig file. For example:
+export KUBECONFIG=~/my-ocp-env/hub/auth/kubeconfig Fork the ansible-edge-gitops-kasten repo on GitHub. It is necessary to fork to preserve customizations you make to the default configuration files.
+Clone the forked copy of this repository.
+git clone git@github.com:your-username/ansible-edge-gitops-kasten.git Create a local copy of the Helm values file that can safely include credentials
+WARNING: DO NOT COMMIT THIS FILE
+You do not want to push personal credentials to GitHub.
+cp values-secret.yaml.template ~/values-secret.yaml vi ~/values-secret.yaml Customize default Kasten settings to specify the configuration of your S3 backup target:
+git checkout -b my-branch vi overrides/values-kasten-defaults.yaml --- kasten: locationProfile: name: default-location-profile bucketName: your-bucket-name # Replace with the AWS S3 bucket name to store backup data region: us-east-1 # Replace with the AWS S3 bucket region immutable: false # Set true only if AWS S3 bucket was created with Versioning/Object Lock enabled; otherwise false protectionPeriod: 120h0m0s # Adjust to specify amount of time for retained RestorePoints to remain immutable. Caution! policyDefaults: presetName: daily-backup ignoreExceptions: false git add overrides/values-kasten-defaults.yaml git commit overrides/values-kasten-defaults.yaml git push origin my-branch Customize the deployment for your cluster (Optional - the defaults in values-global.yaml are designed to work in AWS):
+git checkout -b my-branch vi values-global.yaml git add values-global.yaml git commit values-global.yaml git push origin my-branch Please review the Patterns quick start page. This section describes deploying the pattern using pattern.sh. You can deploy the pattern using the validated pattern operator. If you do use the operator then skip to Validating the Environment below.
+(Optional) Preview the changes. If you&rsquo;d like to review what is been deployed with the pattern, pattern.sh provides a way to show what will be deployed.
+./pattern.sh make show Apply the changes to your cluster. This will install the pattern via the Validated Patterns Operator, and then run any necessary follow-up steps.
+./pattern.sh make install The installation process will take between 45-60 minutes to complete. If you want to know the details of what is happening during that time, the entire process is documented here.
+Installation Validation Check the operators have been installed using OpenShift Console under Operators &gt; Install Operators:
+The screen should like this when installed via make install:
+Under Networking &gt; Routes, click on the URL for the hub-gitops-server and check applications are syncronized/syncronizing:
+All applications will sync, but this takes time as ODF has to completely install, and OpenShift Virtualization cannot provision VMs until the metal node has been fully provisioned and ready. Additionally, the Dynamic Provision Kiosk Template in AAP must complete; it can only start once the VMs have provisioned and are running.
+While the metal node is building, the VMs in OpenShift console will show as &ldquo;Unschedulable.&rdquo; This is normal and expected, as the VMs themselves cannot run until the metal node completes provisioning and is ready.
+Under Virtualization &gt; Virtual Machines, the virtual machines will eventually show as &ldquo;Running.&rdquo; Once they are in &ldquo;Running&rdquo; state the Provisioning workflow will run on them, and install Firefox, Kiosk mode, and the Ignition application on them:
+Finally, the VM Consoles will show the Ignition introduction screen. You can choose any of these options; this tutorial assumes you chose &ldquo;Ignition&rdquo;:
+You should be able to login to the application with the userid &ldquo;admin&rdquo; and the password you specified as the GATEWAY_ADMIN_PASSWORD in container_extra_params in your values-secret.yaml file.
+Infrastructure Elements of this Pattern Ansible Automation Platform A fully functional installation of the Ansible Automation Platform operator is installed on your OpenShift cluster to configure and maintain the VMs for this demo. AAP maintains a dynamic inventory of kiosk machines and can configure a VM from template to fully functional kiosk in about 10 minutes.
+OpenShift Virtualization OpenShift Virtualization is a Kubernetes-native way to run virtual machine workloads. It is used in this pattern to host VMs simulating an Edge environment; the chart that configures the VMs is designed to be flexible to allow easy customization to model different VM sizes, mixes, versions and profiles for future pattern development.
+Inductive Automation Ignition The goal of this pattern is to configure 2 VMs running Firefox in Kiosk mode displaying the demo version of the Ignition application running in a podman container. Ignition is a popular tool in use with Oil and Gas companies; it is included as a real-world example and as an item to spark imagination about what other applications could be installed and managed this way.
+The container used for this pattern is the container image published by Inductive Automation.
+HashiCorp Vault Vault is used as the authoritative source for the Kiosk ssh pubkey via the External Secrets Operator. As part of this pattern HashiCorp Vault has been installed. Refer to the section on Vault.
+Veeam Kasten Veeam Kasten is used to provide Kubernetes-native data protection for OpenShift Virtualization VMs and optionally other Kubernetes workloads as the pattern is further expanded.
+Next Steps See Installation Details for more information on the steps of installation.
+See Ansible Automation Platform for more information on how this pattern uses the Ansible Automation Platform Operator for OpenShift.
+See OpenShift Virtualization for more information on how this pattern uses OpenShift Virtualization.
+See Veeam Kasten for more information on how this pattern uses Veeam Kasten.
+Help &amp; Feedback Report Bugs `,url:"https://validatedpatterns.io/patterns/ansible-edge-gitops-kasten/getting-started/",breadcrumb:"/patterns/ansible-edge-gitops-kasten/getting-started/"},"https://validatedpatterns.io/patterns/ansible-edge-gitops/getting-started/":{title:"Getting Started",tags:[],content:`Deploying the Ansible Edge GitOps Pattern General Prerequisites An OpenShift cluster ( Go to the OpenShift console). See also sizing your cluster. Currently this pattern only supports AWS. It could also run on a baremetal OpenShift cluster, because OpenShift Virtualization supports that; there would need to be some customizations made to support it as the default is AWS. We hope that GCP and Azure will support provisioning metal workers in due course so this can be a more clearly multicloud pattern. A GitHub account (and, optionally, a token for it with repositories permissions, to read from and write to your forks) The helm binary, see here Ansible, which is used in the bootstrap and provisioning phases of the pattern install (and to configure Ansible Automation Platform). Please note that when run on AWS, this pattern will provision an additional worker node, which will be a metal instance (c5n.metal) to run the Edge Virtual Machines. This worker is provisioned through the OpenShift MachineAPI and will be automatically cleaned up when the cluster is destroyed. The use of this pattern depends on having a running Red Hat OpenShift cluster. It is desirable to have a cluster for deploying the GitOps management hub assets and a separate cluster(s) for the managed cluster(s).
+If you do not have a running Red Hat OpenShift cluster you can start one on a public or private cloud by using Red Hat&rsquo;s cloud service.
+Credentials Required in Pattern In addition to the openshift cluster, you will need to prepare a number of secrets, or credentials, which will be used in the pattern in various ways. To do this, copy the values-secret.yaml template to your home directory as values-secret.yaml and replace the explanatory text as follows:
+AWS Credentials (an access key and a secret key). These are used to provision the metal worker in AWS (which hosts the VMs). If the portworx variant of the pattern is used, these credentials will be used to modify IAM rules to allow portworx to run correctly. --- # NEVER COMMIT THESE VALUES TO GIT version: &#34;2.0&#34; secrets: - name: aws-creds fields: - name: aws_access_key_id value: &#34;An aws access key that can provision VMs and manage IAM (if using portworx)&#34; - name: aws_secret_access_key value: &#34;An aws access secret key that can provision VMs and manage IAM (if using portworx)&#34; A username and SSH Keypair (private key and public key). These will be used to provide access to the Kiosk VMs in the demo. - name: kiosk-ssh fields: - name: username value: &#39;Username of user to attach privatekey and publickey to - cloud-user is a typical value&#39; - name: privatekey value: &#39;Private ssh key of the user who will be able to elevate to root to provision kiosks&#39; - name: publickey value: &#39;Public ssh key of the user who will be able to elevate to root to provision kiosks&#39; A Red Hat Subscription Management username and password. These will be used to register Kiosk VM templates to the Red Hat Content Delivery Network and install content on the Kiosk VMs to run the demo. - name: rhsm fields: - name: username value: &#39;username of user to register RHEL VMs&#39; - name: password value: &#39;password of rhsm user in plaintext&#39; Container &ldquo;extra&rdquo; arguments which will set the admin password for the ignition application when it&rsquo;s running. - name: kiosk-extra fields: # Default: &#39;--privileged -e GATEWAY_ADMIN_PASSWORD=redhat&#39; - name: container_extra_params value: &#34;Optional extra params to pass to kiosk ignition container, including admin password&#34; A userData block to use with cloud-init. This will allow console login as the user you specify (traditionally cloud-user) with the password you specify. The value in cloud-init is used as the default; roles in the edge-gitops-vms chart can also specify other secrets to use by referencing them in the role block. - name: cloud-init fields: - name: userData value: |- #cloud-config user: &#39;username of user for console, probably cloud-user&#39; password: &#39;a suitable password to use on the console&#39; chpasswd: { expire: False } A manifest file with an entitlement to run Ansible Automation Platform. This file (which will be a .zip file) will be posted to to Ansible Automation Platform instance to enable its use. Instructions for creating a manifest file can be found here - name: aap-manifest fields: - name: b64content path: &#39;full pathname of file containing Satellite Manifest for entitling Ansible Automation Platform&#39; base64: true Prerequisites for deployment via make install If you are going to install via make install from your workstation, you will need the following tools and packages:
+{% include prerequisite-tools.md %}
+And additionally, the following ansible collections:
+community.okd redhat_cop.controller_configuration awx.awx To see what collections are installed:
+ansible-galaxy collection list
+To install a collection that is not currently installed:
+ansible-galaxy collection install &lt;collection&gt;
+How to deploy Login to your cluster using oc login or exporting the KUBECONFIG
+oc login or set KUBECONFIG to the path to your kubeconfig file. For example:
+export KUBECONFIG=~/my-ocp-env/hub/auth/kubeconfig Fork the ansible-edge-gitops repo on GitHub. It is necessary to fork to preserve customizations you make to the default configuration files.
+Clone the forked copy of this repository.
+git clone git@github.com:your-username/ansible-edge-gitops.git Create a local copy of the Helm values file that can safely include credentials
+WARNING: DO NOT COMMIT THIS FILE
+You do not want to push personal credentials to GitHub.
+cp values-secret.yaml.template ~/values-secret.yaml vi ~/values-secret.yaml Customize the deployment for your cluster (Optional - the defaults in values-global.yaml are designed to work in AWS):
+git checkout -b my-branch vi values-global.yaml git add values-global.yaml git commit values-global.yaml git push origin my-branch Please review the Patterns quick start page. This section describes deploying the pattern using pattern.sh. You can deploy the pattern using the validated pattern operator. If you do use the operator then skip to Validating the Environment below.
+(Optional) Preview the changes. If you&rsquo;d like to review what is been deployed with the pattern, pattern.sh provides a way to show what will be deployed.
+./pattern.sh make show Apply the changes to your cluster. This will install the pattern via the Validated Patterns Operator, and then run any necessary follow-up steps.
+./pattern.sh make install The installation process will take between 45-60 minutes to complete. If you want to know the details of what is happening during that time, the entire process is documented here.
+Installation Validation Check the operators have been installed using the OpenShift console
+OpenShift Console Web UI -&gt; Installed Operators The screen should like this when installed via make install:
+Check all applications are synchronised Under the project ansible-edge-gitops-hub click on the URL for the hubgitopsserver. All applications will sync, but this takes time as ODF has to completely install, and OpenShift Virtualization cannot provision VMs until the metal node has been fully provisioned and ready. Additionally, the Dynamic Provision Kiosk Template in AAP must complete; it can only start once the VMs have provisioned and are running:
+While the metal node is building, the VMs in OpenShift console will show as &ldquo;Unschedulable.&rdquo; This is normal and expected, as the VMs themselves cannot run until the metal node completes provisioning and is ready. Under Virtualization &gt; Virtual Machines, the virtual machines will eventually show as &ldquo;Running.&rdquo; Once they are in &ldquo;Running&rdquo; state the Provisioning workflow will run on them, and install Firefox, Kiosk mode, and the Ignition application on them: Finally, the VM Consoles will show the Ignition introduction screen. You can choose any of these options; this tutorial assumes you chose &ldquo;Ignition&rdquo;: You should be able to login to the application with the userid &ldquo;admin&rdquo; and the password you specified as the GATEWAY_ADMIN_PASSWORD in container_extra_params in your values-secret.yaml file. Please see Installation Details for more information on the steps of installation.
+Please see Ansible Automation Platform for more information on how this pattern uses the Ansible Automation Platform Operator for OpenShift.
+Please see OpenShift Virtualization for more information on how this pattern uses OpenShift Virtualization.
+Infrastructure Elements of this Pattern Ansible Automation Platform A fully functional installation of the Ansible Automation Platform operator is installed on your OpenShift cluster to configure and maintain the VMs for this demo. AAP maintains a dynamic inventory of kiosk machines and can configure a VM from template to fully functional kiosk in about 10 minutes.
+OpenShift Virtualization OpenShift Virtualization is a Kubernetes-native way to run virtual machine workloads. It is used in this pattern to host VMs simulating an Edge environment; the chart that configures the VMs is designed to be flexible to allow easy customization to model different VM sizes, mixes, versions and profiles for future pattern development.
+Inductive Automation Ignition The goal of this pattern is to configure 2 VMs running Firefox in Kiosk mode displaying the demo version of the Ignition application running in a podman container. Ignition is a popular tool in use with Oil and Gas companies; it is included as a real-world example and as an item to spark imagination about what other applications could be installed and managed this way.
+The container used for this pattern is the container image published by Inductive Automation.
+HashiCorp Vault Vault is used as the authoritative source for the Kiosk ssh pubkey via the External Secrets Operator. As part of this pattern HashiCorp Vault has been installed. Refer to the section on Vault.
+Next Steps Help &amp; Feedback Report Bugs `,url:"https://validatedpatterns.io/patterns/ansible-edge-gitops/getting-started/",breadcrumb:"/patterns/ansible-edge-gitops/getting-started/"},"https://validatedpatterns.io/patterns/devsecops/getting-started/":{title:"Getting Started",tags:[],content:`Deploying the Multicluster DevSecOps Pattern Prerequisites An OpenShift cluster (Go to the OpenShift console). Cluster must have a dynamic StorageClass to provision PersistentVolumes. See also sizing your cluster. A second OpenShift cluster for development using secure CI pipelines. A third OpenShift cluster for production. (optional but desirable) A GitHub account (and a token for it with repositories permissions, to read from and write to your forks) Tools Podman and Git. (see below) If you do not have running Red Hat OpenShift clusters you can start one on a public or private cloud by using Red Hat&rsquo;s cloud service.
+Credentials Required in Pattern In addition to the openshift cluster, you will need to prepare a number of secrets, or credentials, which will be used in the pattern in various ways. To do this, copy the values-secret.yaml template to your home directory as values-secret.yaml and replace the explanatory text as follows:
+Your git repository username and password. The password must be base64 encoded. --- secrets: # NEVER COMMIT THESE VALUES TO GIT git: # Go to: https://github.com/settings/tokens # Then: echo -n &#39;your string value&#39; | base64 username: USERNAME password: &#39;encoded password in single quotes&#39; You application secret. TBD This may change when the application is changed. --- secrets: # NEVER COMMIT THESE VALUES TO GIT config-demo: # Secret used for demonstrating vault storage, external secrets, and ACM distribution secure secret: PLAINTEXT Preparing to deploy Install the installation tooling dependencies. See Patterns quick start
+Git command line tool (git) Podman command line tool (podman) Fork the Multicluster DevSecOps repository on GitHub. It is necessary to fork because your fork will be updated as part of the GitOps and DevSecOps processes. The Fork information and pull down menu can be found on the top right of the GitHub page for a pattern. Select the pull down an select Create a new fork.
+Clone the forked copy of the multicluster-devsecops repository. Use branch v1.0. (Clone in an appropriate sub-dir)
+git clone git@github.com:{your-username}/multicluster-devsecops.git cd multicluster-devsecops git checkout v1.0 You could create your own branch where your specific values will be pushed to:
+git checkout -b my-branch A values-secret.yaml file is used to automate setup of secrets needed for:
+A Git repository (E.g. Github, GitLab etc.) Quay registry deployment secrets. Any application secrets that are needed. DO NOT COMMIT THIS FILE. You do not want to push personal credentials to GitHub. Instead copy the template file values-secret.yaml.template to your home directory. Change the values in that file to ones that fit your environment.
+cp values-secret.yaml.template ~/values-secret.yaml vi ~/values-secret.yaml Customize the deployment for your cluster. Change the appropriate values in values-global.yaml
+vi values-global.yaml git add values-global.yaml git commit values-global.yaml git push origin my-branch Getting Started Video Make sure to set up the values-secret.yaml and values-global.yaml correctly (see above). For a demonstration of the deployment, click on the image below to launch the video.
+How to deploy Please review the Patterns quick start page. This section describes deploying the pattern using pattern.sh. You can deploy the pattern using the validated pattern operator. If you do use the operator then skip to Validating the Environment below.
+Preview the changes. If you&rsquo;d like to review what is been deployed with the pattern, pattern.sh provides a way to show what will be deployed.
+./pattern.sh make show Login to your cluster using oc login or exporting the kubernetes kubeconfig file with KUBECONFIG:
+oc login or
+export KUBECONFIG=~/&lt;path-to-kubeconfig/kubeconfig Apply the changes to your cluster
+./pattern.sh make install Validating the Environment Check the operators have been installed
+OpenShift Console UI -&gt; Installed Operators Navigate to the OpenShift GitOps instances using the links on the top right hand side of the screen.
+The most important ArgoCD instance to examine at this point is hub-gitops-server. This is where all the applications for the hub (datacenter), including the test environment, can be tracked.
+Apply the secrets from the values-secret.yaml to the secrets management Vault. This can be done through Vault&rsquo;s UI - manually without the file. The required secrets and scopes are:
+secret/git git username &amp; password (GitHub token) secret/quay The admin username and password and email. secret/imageregistry Quay.io or DockerHub username &amp; password Or you can set up the secrets using the command-line by running the following (Ansible) playbook.
+scripts/setup-secrets.yaml Using the Vault UI check that the secrets have been setup.
+For more information on secrets management see here. For information on Hashicorp&rsquo;s Vault see here
+Check all applications are synchronized in OpenShift GitOps.
+Check the ACM policy deployment After ACM is installed a message regarding a &ldquo;Web console update is available&rdquo; may be displayed. Click on the &ldquo;Refresh web console&rdquo; link.
+Navigate to the ACM hub console. On the upper-left side you&rsquo;ll see a pull down labeled &ldquo;local-cluster&rdquo;. Click on this and select &ldquo;All Clusters&rdquo; from this pull down. This will navigate to the ACM console and to its &ldquo;Clusters&rdquo; section
+The Governance dashboard shows high level information on Policy set violations and Policy violations.
+Navigate to the Governance page and select the Policy sets Governance tab. There are two policy sets deployed, one for the hub, openshift-plus-hub, and one for managed clusters, openshift-plus-managed.
+Explore the Policies tab and select some policies to examine. The image below shows and example of ACM policy status for a three cluster deployment.
+Checking the ACS deployment Select the stackrox Project (namespace). Navigate to the OCP Networking-&gt;Routes page. Click on the central route location URL. It might take a few minutes for this link to be active. When it does it will launch a new tab with the ACS Central login page.
+Return to the OCP console tab and navigate to the Workload-&gt;Secrets page. Find the central-htpasswd secret and select it.
+On the central-htpasswd page, scroll to the Data section and select the copy icon on the right in the password field.
+Return to the ACS Central tab and paste the password into the password field. Make sure that the Username is admin.
+This will bring you to the ACS Central dashboard page. At first it may not show any clusters showing but as the ACS secured deployment on the hub syncs with ACS central on the hub then information will start to show.
+Return to this dashboard later after deploying the development and production clusters so you can see their information in this dashboard. All clusters in this pattern are ACS secured and therefore ought to show up in this dashboard when those clusters join the hub and are fully deployed.
+Check the Quay deployment Select the quay-enterprise project (namespace). Navigate to the OCP Networking-&gt;Routes page. Click on the quay-registry-quay route location URL (standard Quay naming apparently). It might take a few minutes for this link to be active. When it does it will launch a new tab with the Quay login page.
+An initial quayadmin account has already been created for you as part of the deployment. The password is quayadmin123. If you want to change initial admin user name and password you can do so by editing the charts/hub/quay/values.yaml or by adding those entries to the values-global.yaml file. Log in using the username and password.
+After logging in, the private Quay registry dashboard will be displayed.
+Completing the Quay Bridge with a bearer token Managed clusters use a Quay Bridge in order to provide integration between the cluster and Quay Enterprise running on the hub/central cluster. The Quay Bridge looks like a local OpenShift registry but acts as a proxy to the Quay Enterprise registry. Currently there is a manual step to completing the Quay Bridge setup for managed clusters.
+Log in to Red Hat Quay through the web UI.
+Select the organization for which the external application will be configured.
+On the navigation pane, select Applications.
+Select Create New Application and enter a name for the new application, for example, openshift.
+On the OAuth Applications page, select your application, for example, devel-automation.
+On the navigation pane, select Generate Token.
+Select the following fields and press Generate Access Token at the bottom of the page:
+Administer Organization
+Administer Repositories
+Create Repositories
+View all visible repositories
+Read/Write to any accessible repositories
+Administer User
+Read User Information
+Review the assigned permissions.
+Select Authorize Application and then confirm confirm the authorization by selecting Authorize Application at the bottom of the page.
+Save/copy the generated access token.
+At a command line prompt that has KUBECONFIG set to the central/hub cluster&rsquo;s auth/kubeconfig file, run the following command with the token that was saved/copied above.
+$ oc create secret -n openshift-operators generic quay-integration --from-literal=token=&lt;access_token&gt;
+There is a ACM policy that will make sure that this is copied out to the managed clusters. If there are any problems with the managed cluster&rsquo;s Quay Bridge quay-integration token, you can run the same command on the managed cluster.
+Creating an ACS/Quay integration Advanced Cluster Security needs to be integrated with Quay Enterprise registry. Currently there is no way to automate this as it requires the above manual step to generate the OAuth token.
+On the ACS console, under ==Platform Configuration== on the left hand side, select ==Integrations==.
+Under Image Integrations select ==Red Hat Quay.io==
+In the Integrations &gt; Quay.io page select ==New Integration== and fill out the form: Give it a name like hub-quay and select Registry as the type. Provide the URL for Quay Enterprise and the OAuth token generated in above. Press ==Save==. Here is an example.
+Next Steps Help &amp; Feedback{: .btn .fs-5 .mb-4 .mb-md-0 .mr-2 } Report Bugs{: .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:
+Add a dedicated development cluster to deploy the CI pipelines using ACM
+Add a dedicated production cluster to deploy production using ACM
+Once the hub, production and devel clusters have been deployed you will want to check out and test the Multi-Cluster DevSecOps demo code. You can find that here TBD
+a. Making configuration changes with GitOps TBD a. Making application changes using DevOps TBD
+Uninstalling Probably wont work
+Turn off auto-sync
+helm upgrade manuela . --values ~/values-secret.yaml --set global.options.syncPolicy=Manual
+Remove the ArgoCD applications (except for manuela-datacenter)
+a. Browse to ArgoCD a. Go to Applications a. Click delete a. Type the application name to confirm a. Chose &ldquo;Foreground&rdquo; as the propagation policy a. Repeat
+Wait until the deletions succeed
+tbd should be the only remaining application
+Complete the uninstall
+helm delete tbd
+Check all namespaces and operators have been removed
+`,url:"https://validatedpatterns.io/patterns/devsecops/getting-started/",breadcrumb:"/patterns/devsecops/getting-started/"},"https://validatedpatterns.io/patterns/industrial-edge/getting-started/":{title:"Getting Started",tags:[],content:`Deploying the Industrial Edge Pattern Prerequisites An OpenShift cluster (Go to the OpenShift console). Cluster must have a dynamic StorageClass to provision PersistentVolumes. See also sizing your cluster.
+(Optional) A second OpenShift cluster for edge/factory
+A GitHub account (and a token for it with repositories permissions, to read from and write to your forks)
+A quay account with the following repositories set as public:
+http-ionic httpd-ionic iot-anomaly-detection iot-consumer iot-frontend iot-software-sensor The use of this blueprint depends on having at least one running Red Hat OpenShift cluster. It is desirable to have a cluster for deploying the data center assets and a separate cluster(s) for the factory assets.
+If you do not have a running Red Hat OpenShift cluster you can start one on a public or private cloud by using Red Hat&rsquo;s cloud service.
+Prerequisites For installation tooling dependencies, see Patterns quick start
+How to deploy Fork the industrial-edge repository on GitHub. It is necessary to fork because your fork will be updated as part of the GitOps and DevOps processes.
+Fork the manuela-dev repository on GitHub. It is necessary to fork this repository because the GitOps framework will push tags to this repository that match the versions of software that it will deploy.
+Clone the forked copy of the industrial-edge repository. Create a deployment branch using the branch v2.3.
+git clone git@github.com:{your-username}/industrial-edge.git cd industrial-edge git checkout v2.3 git switch -c deploy-v2.3 A values-secret-industrial-edge.yaml file is used to automate setup of secrets needed for:
+A git repository hosted on a service such as GitHub, GitLab, or so on. A container image registry (E.g. Quay) S3 storage (E.g. AWS) DO NOT COMMIT THIS FILE. You do not want to push personal credentials to GitHub.
+cp values-secret.yaml.template ~/values-secret-industrial-edge.yaml vi ~/values-secret-industrial-edge.yaml Customize the following secret values.
+version: &#34;2.0&#34; secrets: - name: imageregistry fields: # E.G. Quay -&gt; Robot Accounts -&gt; Robot Login - name: username value: &lt;Your-Robot-Account&gt; - name: password value: &lt;Your-RobotAccount-Password&gt; - name: git fields: # Go to: https://github.com/settings/tokens - name: username value: &lt;github-user&gt; - name: password value: &lt;github-token&gt; - name: aws fields: - name: aws_access_key_id ini_file: ~/.aws/credentials ini_key: aws_access_key_id - name: aws_secret_access_key ini_file: ~/.aws/credentials ini_key: aws_secret_access_key Customize the deployment for your cluster. Change the appropriate values in values-global.yaml
+main: clusterGroupName: datacenter global: pattern: industrial-edge options: useCSV: False syncPolicy: Automatic installPlanApproval: Automatic imageregistry: account: PLAINTEXT hostname: quay.io type: quay git: hostname: github.com account: PLAINTEXT #username: PLAINTEXT email: SOMEWHERE@EXAMPLE.COM dev_revision: main s3: bucket: name: BUCKETNAME region: AWSREGION message: aggregation: count: 50 custom: endpoint: enabled: false vi values-global.yaml git add values-global.yaml git commit -m &#34;Added personal values to values-global&#34; values-global.yaml git push origin deploy-v2.3 You can deploy the pattern using the Validated Patterns Operator directly. If you deploy the pattern using the Validated Patterns Operator, installed through Operator Hub, you will need to run ./pattern.sh make load-secrets through a terminal session on your laptop or bastion host.
+If you deploy the pattern through a terminal session on your laptop or bastion host login to your cluster by using the oc login command or by exporting the KUBECONFIG file.
+oc login or
+export KUBECONFIG=~/my-ocp-cluster/auth/kubeconfig Apply the changes to your cluster from the root directory of the pattern.
+./pattern.sh make install The make install target deploys the Validated Patterns Operator, all the resources that are defined in the values-datacenter.yaml and runs the make load-secrets target to load the secrets configured in your values-secrets-industrial-edge.yaml file.
+Validating the Environment In the OpenShift Container Platform web console, navigate to the Operators → OperatorHub page.
+Verify that the following Operators are installed on the HUB cluster:
+Operator Name Namespace ------------------------------------------------------ advanced-cluster-management open-cluster-management amq-broker-rhel8 manuela-tst-all amq-streams manuela-data-lake red-hat-camel-k manuela-data-lake seldon-operator manuela-ml-workspace openshift-pipelines-operator- openshift-operators opendatahub-operator openshift-operators patterns-operator openshift-operators Access the ArgoCD environment
+You can find the ArgoCD application links listed under the Red Hat applications in the OpenShift Container Platform web console.
+You can also obtain the ArgoCD URLs and passwords (optional) by displaying the fully qualified domain names, and matching login credentials, for all ArgoCD instances:
+ARGO_CMD=\`oc get secrets -A -o jsonpath=&#39;{range .items[*]}{&#34;oc get -n &#34;}{.metadata.namespace}{&#34; routes; oc -n &#34;}{.metadata.namespace}{&#34; extract secrets/&#34;}{.metadata.name}{&#34; --to=-\\\\n&#34;}{end}&#39; | grep gitops-cluster\` CMD=\`echo $ARGO_CMD | sed &#39;s|- oc|-;oc|g&#39;\` eval $CMD The result should look something like:
+NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD datacenter-gitops-server datacenter-gitops-server-industrial-edge-datacenter.apps.mycluster.mydomain.com datacenter-gitops-server https passthrough/Redirect None # admin.password REDACTED NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD factory-gitops-server factory-gitops-server-industrial-edge-factory.apps.mycluster.mydomain.com factory-gitops-server https passthrough/Redirect None # admin.password REDACTED NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD cluster cluster-openshift-gitops.apps.mycluster.mydomain.com cluster 8080 reencrypt/Allow None kam kam-openshift-gitops.apps.mycluster.mydomain.com kam 8443 passthrough/None None openshift-gitops-server openshift-gitops-server-openshift-gitops.apps.mycluster.mydomain.com openshift-gitops-server https passthrough/Redirect None # admin.password REDACTED The most important ArgoCD instance to examine at this point is data-center-gitops-server. This is where all the applications for the datacenter, including the test environment, can be tracked.
+Apply the secrets from the values-secret-industrial-edge.yaml to the secrets management Vault. This can be done through Vault&rsquo;s UI - manually without the file. The required secrets and scopes are:
+secret/hub/git git username &amp; password (GitHub token) secret/hub/imageregistry Quay or DockerHub username &amp; password secret/hub/aws - AWS values read from your ~/.aws/credentials Using the Vault UI check that the secrets have been setup.
+For more information on secrets management see here. For information on Hashicorp&rsquo;s Vault see here
+Check all applications are synchronised
+Next Steps Help &amp; Feedback{: .btn .fs-5 .mb-4 .mb-md-0 .mr-2 } Report Bugs{: .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:
+Add a dedicated cluster to deploy the factory pieces using ACM
+Once the data center and the factory have been deployed you will want to check out and test the Industrial Edge 2.0 demo code. You can find that here
+a. Making configuration changes with GitOps a. Making application changes using DevOps a. Making AI/ML model changes with DevOps
+Uninstalling We currently do not support uninstalling this pattern.
+`,url:"https://validatedpatterns.io/patterns/industrial-edge/getting-started/",breadcrumb:"/patterns/industrial-edge/getting-started/"},"https://validatedpatterns.io/patterns/medical-diagnosis-amx/getting-started/":{title:"Getting Started",tags:[],content:` Deploying the Intel AMX accelerated Medical Diagnosis pattern Prerequisites An OpenShift Container Platform cluster
+To create an OpenShift Container Platform cluster, go to the Red Hat Hybrid Cloud console and select Services -&gt; Containers -&gt; Create cluster.
+The cluster must have a dynamic StorageClass to provision PersistentVolumes. It was tested with ODF (OpenShift Data Foundation) or LVM Storage solutions. CephFS should be set as a default Storage Class - Setup Guide
+Cluster sizing requirements.
+OpenShift Container Platform Cluster must have Image Registry - Setup Guide
+A GitHub account and a token for it with repositories permissions, to read from and write to your forks.
+An S3-capable Storage (OpenShift Data Foundation is recommended) set up in your private cloud for the x-ray images
+The Helm binary, see Installing Helm For installation tooling dependencies, see Patterns quick start.
+The Intel AMX accelerated Medical Diagnosis pattern does not have a dedicated hub or edge cluster.
+Preparing for deployment Procedure Fork the medical-diagnosis repository on GitHub. You must fork the repository because your fork will be updated as part of the GitOps and DevOps processes.
+Clone the forked copy of this repository.
+$ git clone git@github.com:&lt;your-username&gt;/amx-accelerated-medical-diagnosis.git Create a local copy of the Helm values file that can safely include credentials.
+Do not commit this file. You do not want to push personal credentials to GitHub.
+Run the following commands:
+$ cp values-secret.yaml.template ~/values-secret-medical-diagnosis.yaml $ vi ~/values-secret-medical-diagnosis.yaml Example values-secret.yaml file version &#34;2.0&#34; secrets: # NEVER COMMIT THESE VALUES TO GIT # Database login credentials and configuration - name: xraylab fields: - name: database-user value: xraylab - name: database-host value: xraylabdb - name: database-db value: xraylabdb - name: database-master-user value: xraylab - name: database-password onMissingValue: generate vaultPolicy: validatedPatternDefaultPolicy - name: database-root-password onMissingValue: generate vaultPolicy: validatedPatternDefaultPolicy - name: database-master-password onMissingValue: generate vaultPolicy: validatedPatternDefaultPolicy # Grafana Dashboard admin user/password - name: grafana fields: - name: GF_SECURITY_ADMIN_USER: value: root - name: GF_SECURITY_ADMIN_PASSWORD: onMissingValue: generate vaultPolicy: validatedPatternDefaultPolicy By default, Vault password policy generates the passwords for you. However, you can create your own passwords.
+When defining a custom password for the database users, avoid using the $ special character as it gets interpreted by the shell and will ultimately set the incorrect desired password.
+To customize the deployment for your cluster, update the values-global.yaml file by running the following commands:
+$ git checkout -b my-branch $ vi values-global.yaml Replace &#39;bucketSource&#39; value. User can set any bucket name without special signs (besides &#39;-&#39;) and numbers.
+...omitted datacenter: cloudProvider: PROVIDE_CLOUDPROVIDER # Not required for on-prem storageClassName: &#34;ocs-storagecluster-cephfs&#34; # Default filesystem storage used on on-prem cluster, can be changed by user region: PROVIDE_REGION # Not required for on-prem clustername: &#34;&#34; # Not required for on-prem, pattern uses on-prem cluster value instead domain: &#34;&#34; # Not required for on-prem, pattern uses on-prem cluster value instead s3: # Values for S3 bucket access # bucketSource: &#34;provide s3 bucket name where images are stored&#34; bucketSource: &#34;PROVIDE_BUCKET_SOURCE&#34; # Bucket base name used for image-generator and image-server applications. bucketBaseName: &#34;xray-source&#34; $ git add values-global.yaml $ git commit values-global.yaml $ git push origin my-branch To deploy the pattern, you can use the Validated Patterns Operator. If you do use the Operator, skip to validating the environment.
+Installing Validated Pattern this way may cause other components dependent on Vault to not start properly.
+After Validated pattern is installed using operator from OperatorHub user must type in secrets (from values-secret.yaml) into vault manually.
+To preview the changes that will be implemented to the Helm charts, run the following command:
+$ ./pattern.sh make show Login to your cluster by running the following command:
+$ oc login Optional: Set the KUBECONFIG variable for the kubeconfig file path:
+export KUBECONFIG=~/&lt;path_to_kubeconfig&gt; Check the values files before deployment To ensure that you have the required variables to deploy the Medical Diagnosis pattern, run the ./pattern.sh make predeploy command. You can review your values and make updates, if required.
+You must review the following values files before deploying the Medical Diagnosis pattern:
+Values File Description values-secret.yaml
+Values file that includes the secret parameters required by the pattern
+values-global.yaml
+File that contains all the global values used by Helm to deploy the pattern
+Before you run the ./pattern.msh make install command, ensure that you have the correct values for:
+- bucketSource Deploy To apply the changes to your cluster, run the following command:
+$ ./pattern.sh make install If the installation fails, you can go over the instructions and make updates, if required. To continue the installation, run the following command:
+$ ./pattern.sh make update This step might take some time, especially for the OpenShift Data Foundation Operator components to install and synchronize. The ./pattern.sh make install command provides some progress updates during the installation process. It can take up to twenty minutes. Compare your ./pattern.sh make install run progress with the following video that shows a successful installation.
+Verify that the Operators have been installed.
+To verify, in the OpenShift Container Platform web console, navigate to Operators → Installed Operators page.
+Check that the Operator is installed in the openshift-operators namespace and its status is Succeeded. Ensure that OpenShift Data Foundation is listed in the list of installed Operators.
+(Optional) Typing secrets into Vault manually Log into the Vault using the root token, which can be found by executing the command:
+oc -n vault get route vault -ojsonpath=&#39;{.spec.host}&#39; Log into the Vault using root token. Root token to vault can be found by executing command:
+oc -n imperative get secrets vaultkeys -ojsonpath=&#39;{.data.vault_data_json}&#39; | base64 -d At this point user can type into the Vault secret values specified in &#39;values-secret.yaml&#39;
+Using OpenShift GitOps to check on Application progress To check the various applications that are being deployed, you can view the progress of the OpenShift GitOps Operator.
+Obtain the ArgoCD URLs and passwords.
+The URLs and login credentials for ArgoCD change depending on the pattern name and the site names they control. Follow the instructions below to find them, however you choose to deploy the pattern.
+Display the fully qualified domain names, and matching login credentials, for all ArgoCD instances:
+ARGO_CMD=\`oc get secrets -A -o jsonpath=&#39;{range .items[*]}{&#34;oc get -n &#34;}{.metadata.namespace}{&#34; routes; oc -n &#34;}{.metadata.namespace}{&#34; extract secrets/&#34;}{.metadata.name}{&#34; --to=-\\\\n&#34;}{end}&#39; | grep gitops-cluster\` CMD=\`echo $ARGO_CMD | sed &#39;s|- oc|-;oc|g&#39;\` eval $CMD Example output NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD hub-gitops-server hub-gitops-server-medical-diagnosis-hub.apps.wh-medctr.blueprints.rhecoeng.com hub-gitops-server https passthrough/Redirect None # admin.password xsyYU6eSWtwniEk1X3jL0c2TGfQgVpDH NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD cluster cluster-openshift-gitops.apps.wh-medctr.blueprints.rhecoeng.com cluster 8080 reencrypt/Allow None kam kam-openshift-gitops.apps.wh-medctr.blueprints.rhecoeng.com kam 8443 passthrough/None None openshift-gitops-server openshift-gitops-server-openshift-gitops.apps.wh-medctr.blueprints.rhecoeng.com openshift-gitops-server https passthrough/Redirect None # admin.password FdGgWHsBYkeqOczE3PuRpU1jLn7C2fD6 Examine the medical-diagnosis-hub ArgoCD instance. You can track all the applications for the pattern in this instance.
+Check that all applications are synchronized. There are thirteen different ArgoCD applications that are deployed as part of this pattern.
+Set up object storage Modified version of a Medical Diagnosis pattern requires to use on-prem object storage. Instead of a AWS S3 (or other cloud equivalent) user can set up the Ceph RGW object storage. To communicate with its API user can utilize aws-cli. The installation manual is available on Amazon website
+Set up local S3 object storage only after ODF is properly deployed by validated pattern.
+User can extract CEPH_RGW_ENDPOINT by executing the command:
+oc -n openshift-storage get route s3-rgw -ojsonpath=&#39;{.spec.host}&#39; AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY of RGW object store can be found by performing following commands:
+oc -n xraylab-1 get secret s3-secret-bck -ojsonpath=&#39;{.data.AWS_ACCESS_KEY_ID}&#39; | base64 -d oc -n xraylab-1 get secret s3-secret-bck -ojsonpath=&#39;{.data.AWS_SECRET_ACCESS_KEY}&#39; | base64 -d These values are required to properly set up object storage, if any of them is not accessible (user get error while trying to retrieve them) that may be indicator that ODF is not working properly.
+First thing to check is s3-rgw. Please go to ArgoCD dashboard, to odf application and resync s3-rgw component.
+Second thing to do is to go to ArgoCD dashboard, to xraylab-init application and check if job bucket-init and create-s3-secret are done. If not please resync whole application.
+Clone the repository with xray images and push them to the bucket:
+git clone https://github.com/red-hat-data-services/jumpstart-library.git Xray images are stored in the following path in the repo: https://github.com/red-hat-data-services/jumpstart-library/tree/main/demo1-xray-pipeline/base_elements/containers/image-init/base_images
+Set environment variables. Create and configure the bucket:
+export AWS_ACCESS_KEY_ID=$(oc -n xraylab-1 get secret s3-secret-bck -ojsonpath=&#39;{.data.AWS_ACCESS_KEY_ID}&#39; | base64 -d) export AWS_SECRET_ACCESS_KEY=$(oc -n xraylab-1 get secret s3-secret-bck -ojsonpath=&#39;{.data.AWS_SECRET_ACCESS_KEY}&#39; | base64 -d) export CEPH_RGW_ENDPOINT=$(oc -n openshift-storage get route s3-rgw -ojsonpath=&#39;{.spec.host}&#39;) export CEPH_BUCKET_NAME=&#34;PUT_NAME_OF_YOUR_BUCKET&#34; cd jumpstart-library/demo1-xray-pipeline/base_elements/containers/image-init aws --endpoint https://\${CEPH_RGW_ENDPOINT} --no-verify-ssl s3api create-bucket --bucket \${CEPH_BUCKET_NAME} aws --endpoint https://\${CEPH_RGW_ENDPOINT} --no-verify-ssl s3 cp base_images/ s3://\${CEPH_BUCKET_NAME}/ --recursive Note: The CEPH_BUCKET_NAME value should be the same as the bucketSource: &#34;PROVIDE_BUCKET_SOURCE&#34; value specified in the values-global.yaml file.
+Ceph RGW bucket needs specific bucket policy to be applied. To apply policy execute following commands:
+export AWS_ACCESS_KEY_ID=$(oc -n xraylab-1 get secret s3-secret-bck -ojsonpath=&#39;{.data.AWS_ACCESS_KEY_ID}&#39; | base64 -d) export AWS_SECRET_ACCESS_KEY=$(oc -n xraylab-1 get secret s3-secret-bck -ojsonpath=&#39;{.data.AWS_SECRET_ACCESS_KEY}&#39; | base64 -d) export CEPH_RGW_ENDPOINT=$(oc -n openshift-storage get route s3-rgw -ojsonpath=&#39;{.spec.host}&#39;) export CEPH_BUCKET_NAME=&#34;PUT_NAME_OF_YOUR_BUCKET&#34; cd amx-accelerated-medical-diagnosis aws --endpoint https://\${CEPH_RGW_ENDPOINT} --no-verify-ssl s3api put-bucket-policy --bucket \${CEPH_BUCKET_NAME} --policy file://./bucket-policy.json Viewing the Grafana based dashboard Accept the SSL certificates on the browser for the dashboard. In the OpenShift Container Platform web console, go to the Routes for project openshift-storage\`. Click the URL for the s3-rgw.
+Ensure that you see some XML and not the access denied error message.
+While still looking at Routes, change the project to xraylab-1. Click the URL for the image-server. Ensure that you do not see an access denied error message. You must to see a Hello World message.
+Turn on the image file flow. There are three ways to go about this.
+You can go to the command-line (make sure you have KUBECONFIG set, or are logged into the cluster).
+$ oc scale deploymentconfig/image-generator --replicas=1 -n xraylab-1 Or you can go to the OpenShift UI and change the view from Administrator to Developer and select Topology. From there select the xraylab-1 project.
+Right-click on the image-generator pod icon and select Edit Pod count.
+Up the pod count from 0 to 1 and save.
+Alternatively, you can have the same outcome on the Administrator console.
+Go to the OpenShift UI under Workloads, select Deploymentconfigs for Project xraylab-1. Click image-generator and increase the pod count to 1.
+OpenShift GitOps view should be similar to the following:
+All applications should be healthy for the pattern to work correctly, even if some applications may be OutOfSync. In some cases, ODF (OpenShift Data Foundation) may have an OutOfSync status, but this usually does not impact functionality. If any application is in an &#39;unhealthy&#39; state, the common solution is to sync the application. For other issues, please refer to https://validatedpatterns.io/patterns/medical-diagnosis-amx/troubleshooting/.
+Making some changes on the dashboard You can change some of the parameters and watch how the changes effect the dashboard.
+You can increase or decrease the number of image generators.
+$ oc scale deploymentconfig/image-generator --replicas=2 Check the dashboard.
+$ oc scale deploymentconfig/image-generator --replicas=0 Watch the dashboard stop processing images.
+You can also simulate the change of the AI model version - as it’s only an environment variable in the Serverless Service configuration.
+$ oc patch service.serving.knative.dev/risk-assessment --type=json -p &#39;[{&#34;op&#34;:&#34;replace&#34;,&#34;path&#34;:&#34;/spec/template/metadata/annotations/revisionTimestamp&#34;,&#34;value&#34;:&#34;&#39;&#34;$(date +%F_%T)&#34;&#39;&#34;},{&#34;op&#34;:&#34;replace&#34;,&#34;path&#34;:&#34;/spec/template/spec/containers/0/env/0/value&#34;,&#34;value&#34;:&#34;v2&#34;}]&#39; This changes the model version value, and the revisionTimestamp in the annotations, which triggers a redeployment of the service.
+`,url:"https://validatedpatterns.io/patterns/medical-diagnosis-amx/getting-started/",breadcrumb:"/patterns/medical-diagnosis-amx/getting-started/"},"https://validatedpatterns.io/patterns/medical-diagnosis/getting-started/":{title:"Getting Started",tags:[],content:` Deploying the Medical Diagnosis pattern Prerequisites An OpenShift cluster
+To create an OpenShift cluster, go to the Red Hat Hybrid Cloud console.
+Select Services → Containers → Create cluster.
+The cluster must have a dynamic StorageClass to provision PersistentVolumes. See sizing your cluster.
+A GitHub account and a token for it with repositories permissions, to read from and write to your forks.
+An S3-capable Storage set up in your public or private cloud for the x-ray images
+The Helm binary, see Installing Helm For installation tooling dependencies, see Patterns quick start.
+The Medical Diagnosis pattern does not have a dedicated hub or edge cluster.
+Setting up an S3 Bucket for the xray-images An S3 bucket is required for image processing. For information about creating a bucket in AWS S3, see the Utilities section.
+For information about creating the buckets on other cloud providers, see the following links:
+AWS S3
+Azure Blob Storage
+GCP Cloud Storage
+Utilities To use the utilities that are available, export some environment variables for your cloud provider.
+Example for AWS. Ensure that you replace values with your keys: export AWS_ACCESS_KEY_ID=AKXXXXXXXXXXXXX export AWS_SECRET_ACCESS_KEY=gkXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX Create the S3 bucket and copy over the data from the validated patterns public bucket to the created bucket for your demo. You can do this on the cloud providers console or you can use the scripts that are provided in utilities repository.
+$ python s3-create.py -b mytest-bucket -r us-west-2 -p $ python s3-sync-buckets.py -s validated-patterns-md-xray -t mytest-bucket -r us-west-2 Example output Note the name and URL for the bucket for further pattern configuration. For example, you must update these values in a values-global.yaml file, where there is a section for s3:
+Preparing for deployment Procedure Fork the medical-diagnosis repository on GitHub. You must fork the repository because your fork will be updated as part of the GitOps and DevOps processes.
+Clone the forked copy of this repository.
+$ git clone git@github.com:&lt;your-username&gt;/medical-diagnosis.git Create a local copy of the Helm values file that can safely include credentials.
+Do not commit this file. You do not want to push personal credentials to GitHub.
+Run the following commands:
+$ cp values-secret.yaml.template ~/values-secret-medical-diagnosis.yaml $ vi ~/values-secret-medical-diagnosis.yaml Example values-secret.yaml file version &#34;2.0&#34; secrets: # NEVER COMMIT THESE VALUES TO GIT # Database login credentials and configuration - name: xraylab fields: - name: database-user value: xraylab - name: database-host value: xraylabdb - name: database-db value: xraylabdb - name: database-master-user value: xraylab - name: database-password onMissingValue: generate vaultPolicy: validatedPatternDefaultPolicy - name: database-root-password onMissingValue: generate vaultPolicy: validatedPatternDefaultPolicy - name: database-master-password onMissingValue: generate vaultPolicy: validatedPatternDefaultPolicy # Grafana Dashboard admin user/password - name: grafana fields: - name: GF_SECURITY_ADMIN_USER: value: root - name: GF_SECURITY_ADMIN_PASSWORD: onMissingValue: generate vaultPolicy: validatedPatternDefaultPolicy By default, Vault password policy generates the passwords for you. However, you can create your own passwords.
+When defining a custom password for the database users, avoid using the $ special character as it gets interpreted by the shell and will ultimately set the incorrect desired password.
+To customize the deployment for your cluster, update the values-global.yaml file by running the following commands:
+$ git checkout -b my-branch $ vi values-global.yaml Replace instances of PROVIDE_ with your specific configuration
+...omitted datacenter: cloudProvider: PROVIDE_CLOUD_PROVIDER #AWS, AZURE, GCP storageClassName: PROVIDE_STORAGECLASS_NAME #gp3-csi region: PROVIDE_CLOUD_REGION #us-east-2 clustername: PROVIDE_CLUSTER_NAME #OpenShift clusterName domain: PROVIDE_DNS_DOMAIN #example.com s3: # Values for S3 bucket access # Replace &lt;region&gt; with AWS region where S3 bucket was created # Replace &lt;cluster-name&gt; and &lt;domain&gt; with your OpenShift cluster values # bucketSource: &#34;https://s3.&lt;region&gt;.amazonaws.com/&lt;s3_bucket_name&gt;&#34; bucketSource: PROVIDE_BUCKET_SOURCE #validated-patterns-md-xray # Bucket base name used for xray images bucketBaseName: &#34;xray-source&#34; $ git add values-global.yaml $ git commit values-global.yaml $ git push origin my-branch To deploy the pattern, you can use the Validated Patterns Operator. If you do use the Operator, skip to validating the environment.
+To preview the changes that will be implemented to the Helm charts, run the following command:
+$ ./pattern.sh make show Login to your cluster by running the following command:
+$ oc login Optional: Set the KUBECONFIG variable for the kubeconfig file path:
+export KUBECONFIG=~/&lt;path_to_kubeconfig&gt; Check the values files before deployment To ensure that you have the required variables to deploy the Medical Diagnosis pattern, run the ./pattern.sh make predeploy command. You can review your values and make updates, if required.
+You must review the following values files before deploying the Medical Diagnosis pattern:
+Values File Description values-secret.yaml
+Values file that includes the secret parameters required by the pattern
+values-global.yaml
+File that contains all the global values used by Helm to deploy the pattern
+Before you run the ./pattern.msh make install command, ensure that you have the correct values for:
+- domain - clusterName - cloudProvider - storageClassName - region - bucketSource Deploy To apply the changes to your cluster, run the following command:
+$ ./pattern.sh make install If the installation fails, you can go over the instructions and make updates, if required. To continue the installation, run the following command:
+$ ./pattern.sh make update This step might take some time, especially for the OpenShift Data Foundation Operator components to install and synchronize. The ./pattern.sh make install command provides some progress updates during the installation process. It can take up to twenty minutes. Compare your ./pattern.sh make install run progress with the following video that shows a successful installation.
+Verify that the Operators have been installed.
+To verify, in the OpenShift Container Platform web console, navigate to Operators → Installed Operators page.
+Check that the Operator is installed in the openshift-operators namespace and its status is Succeeded. Ensure that OpenShift Data Foundation is listed in the list of installed Operators.
+Using OpenShift GitOps to check on Application progress To check the various applications that are being deployed, you can view the progress of the OpenShift GitOps Operator.
+Obtain the ArgoCD URLs and passwords.
+The URLs and login credentials for ArgoCD change depending on the pattern name and the site names they control. Follow the instructions below to find them, however you choose to deploy the pattern.
+Display the fully qualified domain names, and matching login credentials, for all ArgoCD instances:
+ARGO_CMD=\`oc get secrets -A -o jsonpath=&#39;{range .items[*]}{&#34;oc get -n &#34;}{.metadata.namespace}{&#34; routes; oc -n &#34;}{.metadata.namespace}{&#34; extract secrets/&#34;}{.metadata.name}{&#34; --to=-\\\\n&#34;}{end}&#39; | grep gitops-cluster\` CMD=\`echo $ARGO_CMD | sed &#39;s|- oc|-;oc|g&#39;\` eval $CMD Example output NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD hub-gitops-server hub-gitops-server-medical-diagnosis-hub.apps.wh-medctr.blueprints.rhecoeng.com hub-gitops-server https passthrough/Redirect None # admin.password xsyYU6eSWtwniEk1X3jL0c2TGfQgVpDH NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD cluster cluster-openshift-gitops.apps.wh-medctr.blueprints.rhecoeng.com cluster 8080 reencrypt/Allow None kam kam-openshift-gitops.apps.wh-medctr.blueprints.rhecoeng.com kam 8443 passthrough/None None openshift-gitops-server openshift-gitops-server-openshift-gitops.apps.wh-medctr.blueprints.rhecoeng.com openshift-gitops-server https passthrough/Redirect None # admin.password FdGgWHsBYkeqOczE3PuRpU1jLn7C2fD6 Examine the medical-diagnosis-hub ArgoCD instance. You can track all the applications for the pattern in this instance.
+Check that all applications are synchronized. There are thirteen different ArgoCD applications that are deployed as part of this pattern.
+Viewing the Grafana based dashboard Accept the SSL certificates on the browser for the dashboard. In the OpenShift Container Platform web console, go to the Routes for project openshift-storage\`. Click the URL for the s3-rgw.
+Ensure that you see some XML and not the access denied error message.
+While still looking at Routes, change the project to xraylab-1. Click the URL for the image-server. Ensure that you do not see an access denied error message. You must to see a Hello World message.
+Turn on the image file flow. There are three ways to go about this.
+You can go to the command-line (make sure you have KUBECONFIG set, or are logged into the cluster).
+$ oc scale deploymentconfig/image-generator --replicas=1 -n xraylab-1 Or you can go to the OpenShift UI and change the view from Administrator to Developer and select Topology. From there select the xraylab-1 project.
+Right-click on the image-generator pod icon and select Edit Pod count.
+Up the pod count from 0 to 1 and save.
+Alternatively, you can have the same outcome on the Administrator console.
+Go to the OpenShift UI under Workloads, select Deploymentconfigs for Project xraylab-1. Click image-generator and increase the pod count to 1.
+Making some changes on the dashboard You can change some of the parameters and watch how the changes effect the dashboard.
+You can increase or decrease the number of image generators.
+$ oc scale deploymentconfig/image-generator --replicas=2 Check the dashboard.
+$ oc scale deploymentconfig/image-generator --replicas=0 Watch the dashboard stop processing images.
+You can also simulate the change of the AI model version - as it’s only an environment variable in the Serverless Service configuration.
+$ oc patch service.serving.knative.dev/risk-assessment --type=json -p &#39;[{&#34;op&#34;:&#34;replace&#34;,&#34;path&#34;:&#34;/spec/template/metadata/annotations/revisionTimestamp&#34;,&#34;value&#34;:&#34;&#39;&#34;$(date +%F_%T)&#34;&#39;&#34;},{&#34;op&#34;:&#34;replace&#34;,&#34;path&#34;:&#34;/spec/template/spec/containers/0/env/0/value&#34;,&#34;value&#34;:&#34;v2&#34;}]&#39; This changes the model version value, and the revisionTimestamp in the annotations, which triggers a redeployment of the service.
+`,url:"https://validatedpatterns.io/patterns/medical-diagnosis/getting-started/",breadcrumb:"/patterns/medical-diagnosis/getting-started/"},"https://validatedpatterns.io/patterns/multicloud-gitops-portworx/getting-started/":{title:"Getting Started",tags:[],content:`Deploying the Multicloud GitOps pattern Prerequisite An OpenShift cluster To create an OpenShift cluster, go to the Red Hat Hybrid Cloud console. Select Services -&gt; Containers -&gt; Create cluster. The cluster must have a dynamic StorageClass to provision PersistentVolumes. See sizing your cluster. Optional: A second OpenShift cluster for multicloud demonstration. The git binary and podman. For details see Installing Git and Installing Podman The use of this pattern depends on having at least one running Red Hat OpenShift cluster. It is desirable to have a cluster for deploying the GitOps management hub assets and a separate cluster(s) for the managed cluster(s).
+If you do not have a running Red Hat OpenShift cluster, you can start one on a public or private cloud by using Red Hat&rsquo;s cloud service.
+Procedure For installation tooling dependencies, see link:https://validatedpatterns.io/learn/quickstart/[Patterns quick start].
+{% include prerequisite-tools.md %}
+Fork the rh-multicloud-gitops-pxe repository on GitHub. It is recommended to fork because you can update your fork as part of the GitOps and DevOps processes.
+Clone the forked copy of this repository.
+git clone git@github.com:your-username/multicloud-gitops-pxe.git Create a local copy of the secret values file that can safely include credentials.
+Warning: Do not commit this file. You do not want to push personal credentials to GitHub. Note that if you do not want to customize the secrets, these steps are not needed. The framework generates a random password for the config-demo application.
+cp values-secret.yaml.template ~/values-secret-multicloud-gitops-pxe.yaml vi ~/values-secret-multicloud-gitops-pxe.yaml Customize the deployment for your cluster.
+git checkout -b my-branch vi values-global.yaml git add values-global.yaml git commit values-global.yaml git push origin my-branch You can deploy the pattern by running ./pattern.sh make install or by using the validated pattern operator.
+Deploying the cluster by using the pattern.sh file To deploy the cluster by using the pattern.sh file, complete the following steps:
+Login to your cluster using oc login or exporting the KUBECONFIG.
+oc login or set KUBECONFIG to the path to your kubeconfig file. For example:
+export KUBECONFIG=~/my-ocp-env/hub/auth/kubeconfig Deploy the pattern to your cluster.
+./pattern.sh make install Verify that the Operators have been installed.
+To verify, in the *OpenShift Container Platform web console, navigate to Operators → Installed Operators page. 2.Check that the Operator is installed in the openshift-operators namespace and its status is Succeeded. Verify that all applications are synchronized. Under the project multicloud-gitops-hub click the URL for the hub gitops server. The Vault application is not synched. Multicloud GitOps application demos As part of this pattern, HashiCorp Vault has been installed. Refer to the section on Vault.
+Next steps Deploying the managed cluster applications After the management hub is set up and works correctly, attach one or more managed clusters to the architecture (see diagrams below).
+For instructions on deploying the edge, refer to Managed Cluster Sites.
+Contribute to this pattern: Help &amp; Feedback Report Bugs
+`,url:"https://validatedpatterns.io/patterns/multicloud-gitops-portworx/getting-started/",breadcrumb:"/patterns/multicloud-gitops-portworx/getting-started/"},"https://validatedpatterns.io/patterns/openshift-ai/getting-started/":{title:"Getting Started",tags:[],content:` Deploying the Red Hat OpenShift AI Pattern Prerequisites An OpenShift cluster
+To create an OpenShift cluster, go to the Red Hat Hybrid Cloud console.
+Select Services -&gt; Containers -&gt; Create cluster.
+The cluster must have a dynamic StorageClass to provision PersistentVolumes. See sizing your cluster.
+Optional: A second OpenShift cluster for multicloud demonstration.
+Install the tooling dependencies.
+The use of this pattern depends on having at least one running Red Hat OpenShift cluster. However, consider creating a cluster for deploying the GitOps management hub assets and a separate cluster for the managed cluster.
+If you do not have a running Red Hat OpenShift cluster, you can start one on a public or private cloud by using Red Hat Hybrid Cloud Console.
+Procedure Fork the openshift-ai repository on GitHub.
+Clone the forked copy of this repository.
+git clone git@github.com:your-username/openshift-ai.git If you want a peak under the covers to see what the pattern contains, you can do so with the following command:
+cat values-hub.yaml But don’t worry if it looks intimidating.
+Deploy the pattern by running ./pattern.sh make install or by using the Validated Patterns Operator.
+Deploying the cluster by using the pattern.sh file To deploy the cluster by using the pattern.sh file, complete the following steps:
+Login to your cluster by running the following command:
+oc login Optional: Set the KUBECONFIG variable for the kubeconfig file path:
+export KUBECONFIG=~/&lt;path_to_kubeconfig&gt; Deploy the pattern to your cluster. Run the following command:
+./pattern.sh make install Verify Red Hat OpenShift AI Pattern installation Verify that the Operators have been installed.
+To verify, in the OpenShift Container Platform web console, navigate to Operators → Installed Operators page.
+Set your project to All Projects and verify the operators are isntalled and have a status of Succeeded.
+Verify that all applications are synchronized. Under the project openshift-ai-hub click the URL for the hub gitops server.
+As part of this pattern, HashiCorp Vault has been installed. Refer to the section on Vault.
+Verify installation by checking the OpenShift AI Dashboard Access the OpenShift AI dashboard
+RHODS=https://$(oc get route -n redhat-ods-applications -o jsonpath=&#39;{.spec.host}&#39;) echo \${RHODS} You can also get to the dashboard from the OpenShift Console by selecting the application shortcut icon and then selecting the link for Red Hat OpenShift Ai
+Log in to the Dashboard using your OpenShift credentials. You will find an environment that is ready for further configuration. This pattern provides the fundamental platform pieces to support MLOps workflows. The installation of OpenShift Pipelines enables the immediate use of pipelines if that is the desired approach for deployment.
+`,url:"https://validatedpatterns.io/patterns/openshift-ai/getting-started/",breadcrumb:"/patterns/openshift-ai/getting-started/"},"https://validatedpatterns.io/patterns/rag-llm-gitops/getting-started/":{title:"Getting Started",tags:[],content:`Deploying the demo Following commands will take about 15-20 minutes
+Validated pattern will be deployed
+git clone https://github.com/&lt;&lt;your-username&gt;&gt;/rag-llm-gitops.git cd rag-llm-gitops oc login --token=&lt;&gt; --server=&lt;&gt; # login to Openshift cluster podman machine start # Copy values-secret.yaml.template to ~/values-secret-rag-llm-gitops.yaml. # You should never check these files # Add secrets to the values-secret.yaml that needs to be added to the vault. cp values-secret.yaml.template ~/values-secret-rag-llm-gitops.yaml ./pattern.sh make install RAG Demo Workflow Figure 3. Schematic diagram for workflow of RAG demo with Red Hat OpenShift.
+RAG Data Ingestion Figure 4. Schematic diagram for Ingestion of data for RAG.
+RAG Augmented Query Figure 5. Schematic diagram for RAG demo augmented query.
+In Figure 5, we can see RAG augmented query. The Mistral-7B model is used for language processing. LangChain is used to integrate different tools of the LLM-based application together and to process the PDF files and web pages. A vector database provider such as EDB Postgres for Kubernetes (or Redis), is used to store vectors. HuggingFace TGI is used to serve the Mistral-7B model. Gradio is used for user interface and object storage to store language model and other datasets. Solution components are deployed as microservices in the Red Hat OpenShift Container Platform cluster.
+Download diagrams View and download all of the diagrams above in our open source tooling site.
+Open Diagrams
+Figure 6. Proposed demo architecture with OpenShift AI
+Components deployed Hugging Face Text Generation Inference Server: The pattern deploys a Hugging Face TGIS server. The server deploys mistral-community/Mistral-7B-v0.2 model. The server will require a GPU node. EDB Postgres for Kubernetes / Redis Server: A Vector Database server is deployed to store vector embeddings created from Red Hat product documentation. Populate VectorDb Job: The job creates the embeddings and populates the vector database. LLM Application: This is a Chatbot application that can generate a project proposal by augmenting the LLM with the Red Hat product documentation stored in vector db. Prometheus: Deploys a prometheus instance to store the various metrics from the LLM application and TGIS server. Grafana: Deploys Grafana application to visualize the metrics. Deploying the demo Fork the rag-llm-gitops repo into your organization
+Cloning repository git clone https://github.com/&lt;&lt;your-username&gt;&gt;/rag-llm-gitops.git cd rag-llm-gitops oc login --token=&lt;&gt; --server=&lt;&gt; # login to Openshift cluster podman machine start # Copy values-secret.yaml.template to ~/values-secret-rag-llm-gitops.yaml. # You should never check-in these files # Add secrets to the values-secret.yaml that needs to be added to the vault. cp values-secret.yaml.template ~/values-secret-rag-llm-gitops.yaml Provision GPU MachineSet As a pre-requisite to deploy the application using the validated pattern, GPU nodes should be provisioned along with Node Feature Discovery Operator and NVIDIA GPU operator. To provision GPU Nodes
+Following command will take about 5-10 minutes.
+./pattern.sh make create-gpu-machineset Wait till the nodes are provisioned and running.
+Alternatively, follow the instructions to manually install GPU nodes, Node Feature Discovery Operator and NVIDIA GPU operator.
+Deploy application Note: This pattern supports two types of vector databases, EDB Postgres for Kubernetes, and Redis. By default the pattern will deploy EDB Postgres for Kubernetes as a vector database. To deploy Redis, change the global.db.type parameter to the REDIS value in values-global.yaml.
+--- global: pattern: rag-llm-gitops options: useCSV: false syncPolicy: Automatic installPlanApproval: Automatic # Possible value for db.type = [REDIS, EDB] db: index: docs type: EDB # &lt;--- Default is EDB, Change the db type to REDIS for Redis deployment main: clusterGroupName: hub multiSourceConfig: enabled: true Following commands will take about 15-20 minutes
+Validated pattern will be deployed
+./pattern.sh make install 1: Verify the installation Login to the OpenShift web console. Navigate to the Workloads &ndash;&gt; Pods. Select the rag-llm project from the drop down. Following pods should be up and running. Note: If the hf-text-generation-server is not running, make sure you have followed the steps to configure a node with GPU from the instructions provided above.
+2: Launch the application Click the Application box icon in the header, and select Retrieval-Augmented-Generation (RAG) LLM Demonstration UI It should launch the application
+3: Generate the proposal document It will use the default provider and model configured as part of the application deployment. The default provider is a Hugging Face model server running in the OpenShift. The model server is deployed with this validated pattern and requires a node with GPU.
+Enter any company name
+Enter the product as RedHat OpenShift
+Click the Generate button, a project proposal should be generated. The project proposal also contains the reference of the RAG content. The project proposal document can be Downloaded in the form of a PDF document.
+4: Add an OpenAI provider You can optionally add additional providers. The application supports the following providers
+Hugging Face Text Generation Inference Server OpenAI NVIDIA Click on the Add Provider tab to add a new provider. Fill in the details and click Add Provider button. The provider should be added in the Providers dropdown under Chatbot tab.
+5: Generate the proposal document using OpenAI provider Follow the instructions in step 3 to generate the proposal document using the OpenAI provider.
+6: Rating the provider You can provide rating to the model by clicking on the Rate the model radio button. The rating will be captured as part of the metrics and can help the company which model to deploy in production.
+7: Grafana Dashboard By default, Grafana application is deployed in llm-monitoring namespace.To launch the Grafana Dashboard, follow the instructions below:
+Grab the credentials of Grafana Application Navigate to Workloads &ndash;&gt; Secrets Click on the grafana-admin-credentials and copy the GF_SECURITY_ADMIN_USER, GF_SECURITY_ADMIN_PASSWORD Launch Grafana Dashboard Click the Application box icon in the header, and select Grafana UI for LLM ratings Enter the Grafana admin credentials. Ratings are displayed for each model. `,url:"https://validatedpatterns.io/patterns/rag-llm-gitops/getting-started/",breadcrumb:"/patterns/rag-llm-gitops/getting-started/"},"https://validatedpatterns.io/patterns/retail/getting-started/":{title:"Getting Started",tags:[],content:`Deploying the Retail Pattern Prerequisites An OpenShift cluster (Go to the OpenShift console). Cluster must have a dynamic StorageClass to provision PersistentVolumes. See also sizing your cluster.
+(Optional) A second OpenShift cluster for a second store environment, &ldquo;raleigh&rdquo;.
+A GitHub account
+(Optional) A quay account that can update images; this is if you want to use the pipelines to customize the applications
+(Optional) A quay account with the following repositories set as public, and which you can write to:
+quarkuscoffeeshop-barista quarkuscoffeeshop-counter quarkuscoffeeshop-customerloyalty quarkuscoffeeshop-customermocker quarkuscoffeeshop-inventory quarkuscoffeeshop-kitchen quarkuscoffeeshop-majestic-monolith quarkuscoffeeshop-web These repos comprise the microservices that are in the demo. The public repos (quay.io/hybrid-cloud-patterns/*) contain pre-built images which will be downloaded and used by default; so the demo will run regardless of whether you choose to rebuild the apps or not. This mechanism is provided for transparency purposes (so you can reproduce the same results); or if you want to customize or change the apps themselves in some way.
+The use of this pattern depends on having at least one running Red Hat OpenShift cluster. All of the apps will run on a single cluster; optionally you can use RHACM to apply the store apps to a second cluster.
+If you do not have a running Red Hat OpenShift cluster you can start one on a public or private cloud by using Red Hat&rsquo;s cloud service.
+Prerequisite Tools Install the installation tooling dependencies. You will need:
+{% include prerequisite-tools.md %}
+How to deploy Fork the retail repository on GitHub.
+Clone the forked copy of the retail repo. Use branch \`v1.0'.
+git clone git@github.com:{your-username}/retail.git cd retail git checkout v1.0 You could create your own branch where you specific values will be pushed to:
+git checkout -b my-branch A values-secret.yaml file is used to automate setup of secrets needed for:
+A container image registry (E.g. Quay) DO NOT COMMIT THIS FILE. You do not want to push personal credentials to GitHub.
+cp values-secret.yaml.template ~/values-secret.yaml vi ~/values-secret.yaml Customize the deployment for your cluster. Change the appropriate values in values-global.yaml
+vi values-global.yaml git add values-global.yaml git commit values-global.yaml git push origin my-branch In particular, the values that you need to change are under the imageregistry key, to use your own account and hostname. If you like, you can change the git settings (account, email, hostname to reflect your own account settings).
+If you plan to customize the build of the applications themselves, there revision and imageTag settings for each of them. The defaults should suffice if you just want to see the apps running.
+You can deploy the pattern using the validated pattern operator. If you do use the operator then skip to Validating the Environment below.
+Preview the changes
+./pattern.sh make show Login to your cluster using oc login or exporting the KUBECONFIG
+oc login or
+export KUBECONFIG=~/my-ocp-env/retail-hub Apply the changes to your cluster
+./pattern-util.sh make install This will execute make install in the team&rsquo;s container, which will take a bit to load the first time. It contains ansible and other dependencies so that you do not need to install them on your workstation.
+The default install target will:
+Install the pattern via the operator Load the imageregistry secret into the vault Start the application build pipelines If you chose not to put in your registry credential, make install cannot complete successfully because it waits for the secret to be populated before starting the pipelines.
+If you do not want to run the (optional) components, another install target is provided:
+./common/scripts/pattern-util.sh make install-no-pipelines This skips the vault setup and the pipeline builds, but still installs both Vault and the Pipelines operator, so if you want to run those in your installation later, you can run make install to enable them.
+For more information on secrets management see here. For information on Hashicorp&rsquo;s Vault see here
+Validating the Environment Check the operators have been installed
+UI -&gt; Installed Operators The OpenShift console menu should look like this. We will use it to validate that the pattern is working as expected:
+Check on the pipelines, if you chose to run them. They should all complete successfully:
+Ensure that the Hub ArgoCD instance shows all of its apps in Healthy and Synced status once all of the images have been built:
+We will go to the Landing Page, which will present the applications in the pattern:
+Clicking on the Store Web Page will place us in the Quarkus Coffeeshop Demo:
+Clicking on the TEST Store Web Page will place us in a separate copy of the same demo.
+Clicking on the respective Kafdrop links will go to a Kafdrop instance that allows inspection of each of the respective environments.
+Next Steps Help &amp; Feedback{: .btn .fs-5 .mb-4 .mb-md-0 .mr-2 } Report Bugs{: .btn .btn-red .fs-5 .mb-4 .mb-md-0 .mr-2 }
+`,url:"https://validatedpatterns.io/patterns/retail/getting-started/",breadcrumb:"/patterns/retail/getting-started/"},"https://validatedpatterns.io/patterns/travelops/getting-started/":{title:"Getting Started",tags:[],content:` Deploying the TravelOps pattern Prerequisites An OpenShift cluster
+To create an OpenShift cluster, go to the Red Hat Hybrid Cloud console.
+Select Services -&gt; Containers -&gt; Create cluster.
+The cluster must have a dynamic StorageClass to provision PersistentVolumes. See sizing your cluster.
+Optional: A second OpenShift cluster for multicloud demonstration.
+Install the tooling dependencies.
+The use of this pattern depends on having at least one running Red Hat OpenShift cluster. However, consider creating a cluster for deploying the GitOps management hub assets and a separate cluster for the managed cluster.
+If you do not have a running Red Hat OpenShift cluster, you can start one on a public or private cloud by using Red Hat Hybrid Cloud Console.
+Procedure Fork the travelops repository on GitHub.
+Clone the forked copy of this repository.
+git clone git@github.com:your-username/travelops.git Create a local copy of the secret values file that can safely include credentials. Run the following commands:
+cp values-secret.yaml.template ~/values-secret-travelops.yaml version: &#34;2.0&#34; # Ideally you NEVER COMMIT THESE VALUES TO GIT (although if all passwords are # automatically generated inside the vault this should not really matter) secrets: - name: mysql-credentials vaultPrefixes: - global fields: - name: rootpasswd onMissingValue: generate vaultPolicy: validatedPatternDefaultPolicy # Uncomment the following if you want to enable HTPasswd oAuth # - name: htpasswd # vaultPrefixes: # - global # fields: # - name: htpasswd # path: &#39;/path/to/users.htpasswd&#39; Do not commit this file. You do not want to push personal credentials to GitHub. If you do not want to customize the secrets, these steps are not needed. The framework generates a random password for the config-demo application.
+Customize the deployment for your cluster. Run the following command:
+git switch -c my-branch vi values-hub.yaml git add values-hub.yaml git commit values-hub.yaml git push origin my-branch Deploy the pattern by running ./pattern.sh make install or by using the Validated Patterns Operator.
+Deploying the cluster by using the pattern.sh file To deploy the cluster by using the pattern.sh file, complete the following steps:
+Login to your cluster by running the following command:
+oc login Optional: Set the KUBECONFIG variable for the kubeconfig file path:
+export KUBECONFIG=~/&lt;path_to_kubeconfig&gt; Deploy the pattern to your cluster. Run the following command:
+./pattern.sh make install Verify TravelOps Pattern installation Verify that the Operators have been installed.
+To verify, in the OpenShift Container Platform web console, navigate to Operators → Installed Operators page.
+Set your project to All Projects and verify the operators are isntalled and have a status of Succeeded.
+Verify that all applications are synchronized. Under the project travelops-hub click the URL for the hub gitops server.
+As part of this pattern, HashiCorp Vault has been installed. Refer to the section on Vault.
+Verify installation by checking the TravelOps Dashboards Access the Kiali and Travel Control dashboards
+KIALI=https://$(oc get route -n istio-system kiali -o jsonpath=&#39;{.spec.host}&#39;) echo \${KIALI} CONTROL=http://$(oc get route -n istio-system istio-ingressgateway -o jsonpath=&#39;{.spec.host}&#39;) echo \${CONTROL} When we see the 🔒 icon next to our applications and in the top right hand corner of the dashboard it confirms that mTLS is enabled and active in the mesh.
+The &#34;🔒&#34; is present next to the logged in user in top right corner of the window.
+7 applications in the travel-agency tile with the &#34;🔒&#34; next to Istio config
+1 application in the travel-control tile with the &#34;🔒&#34; next to Istio config
+3 applications in the travel-portal tile with the &#34;🔒&#34; next to Istio config
+Review your Kiali dashboard
+Review Travel Agency Application Graph In the Kiali dashboard we can see how all of the various components interact with each other within the service mesh. Just to get a glimpse of what we are able to see let’s take a look at the applications and services in the travel-agency namespace.
+In the left hand menu:
+click Graph
+in the Namespace dropdown, select travel-agency
+exit the menu
+You should see all of the deployments and services that make up the travel-agency application.
+Next Steps To run through the demo, refer to Monitor the Mesh
+Like what you see, but can’t quite put your finger on how you could use a Service Mesh? Check out Ways to customize the Mesh for some ideas!
+`,url:"https://validatedpatterns.io/patterns/travelops/getting-started/",breadcrumb:"/patterns/travelops/getting-started/"},"https://validatedpatterns.io/patterns/mlops-fraud-detection/mfd-running-the-demo/":{title:"Running the Fraud Detection Demo",tags:[],content:` Running the MLOps Fraud Detection Demo The following steps describes how you can use this pattern in a demo.
+Get the MLFlow Route using command-line You can use the OC command to get the hostname through:
+oc get svc mlflow-server -n mlops -o go-template --template=&#39;{{.metadata.name}}.{{.metadata.namespace}}.svc.cluster.local{{println}}&#39; The port you will find with:
+oc get svc mlflow-server -n mlops -o yaml apiVersion: v1 kind: Service metadata: ... spec: clusterIP: 172.31.112.122 clusterIPs: - 172.31.112.122 internalTrafficPolicy: Cluster ipFamilies: - IPv4 ipFamilyPolicy: SingleStack ports: - name: mlflow-server port: 8080 protocol: TCP targetPort: mlflow-server - name: oauth port: 8443 protocol: TCP targetPort: oauth-proxy selector: app.kubernetes.io/instance: mlflow-server app.kubernetes.io/name: mlflow-server sessionAffinity: None type: ClusterIP status: loadBalancer: {} It is the port for spec.ports.name mlflow-server. In this case the server:port is: mlflow-server.mlops.svc.cluster.local:8080. Use this value when creating the work bench:
+MLFLOW_ROUTE=http://mlflow-server.mlops.svc.cluster.local:8080 Create a OpenShift Data Science workbench Start by opening up OpenShift Data Science by clicking image::../images/grid.png in the top right and choosing &#34;Red Hat OpenShift Data Science&#34;.
+Under Data Science Projects, create a new project by selecting &#34;Create data science project&#34;. This is where you will build and train the model. This will also create a namespace in OpenShift which is where the application will be running after the model training is done. In the example the project is called &#39;Credit Card Fraud&#39;.
+You may change the project name to something different but be aware that steps further down in the demo may also need to change.
+After the project has been created, create a workbench where we can run Jupyter. There are a few important settings here that we need to set:
+Name: Credit Fraud Model
+Notebook Image: Standard Data Science
+Deployment Size: Small
+Environment Variable: Add a new one that’s a Config Map → Key/value and enter
+Get value by running the following form the commandline:
+oc get service mlflow-server -n mlops -o go-template --template=&#39;http://{{.metadata.name}}.{{.metadata.namespace}}.svc.cluster.local:8080{{println}}&#39; Key: MLFLOW_ROUTE
+Value: http://&lt;route-to-mlflow&gt;:8080, replacing &lt;route-to-mlflow&gt; and 8080 with the route and port respectfully, that we found in step one. In this case it is http://mlflow-server.mlflow.svc.cluster.local:8080
+Cluster Storage: Create new persistent storage - Call it &#34;Credit Fraud Storage&#34; and set the size to 20GB.
+Open the workbench and login if needed.
+Train the model When inside the workbench (Jupyter), we are going to clone a GitHub repository which contains everything we need to train (and run) our model. You can clone the GitHub repository by pressing the GitHub button in the left side menu (see image), then select &#34;Clone a Repository&#34; and enter this GitHub URL:+
+https://github.com/validatedpatterns/mlops-fraud-detection/tree/main/demo/credit-fraud-detection-demo Figure 1. Open the model folder Open up the folder that was added (credit-fraud-detection-demo). It contains:
+Data for training and evaluating the model.
+A notebook (model.ipynb) inside the model folder with a Deep Neural Network model we will train.
+An application (model_application.py) inside the application folder that fetchs the trained model from MLFlow and runs a prediction on it whenever it receives user input.
+The model.ipynb is used to build and train the model. Open that file and take a look inside. There is documentation outlining what each cell does. Of particular interest for this demo are the last two cells.The second to last cell contains the code for setting up MLFlow tracking:
+mlflow.set_tracking_uri(MLFLOW_ROUTE) mlflow.set_experiment(&#34;DNN-credit-card-fraud&#34;) mlflow.tensorflow.autolog(registered_model_name=&#34;DNN-credit-card-fraud&#34;) mlflow.set_tracking_uri(MLFLOW_ROUTE) points to where to should the MLFlow data. mlflow.set_experiment(&#34;DNN-credit-card-fraud&#34;) tells MLFlow to create an experiment with a name string. In this case it is called &#34;DNN-credit-card-fraud&#34; because it’s a Deep Neural Network. mlflow.tensorflow.autolog(registered_model_name=&#34;DNN-credit-card-fraud&#34;) enables autologging of several variables (such as accuracy, loss, etc) - so there is no need to manually track those variables. It also automatically uploads the model to MLFlow after training completes. Here the model is named the same as the experiment.
+The last cell contains the training code:
+with mlflow.start_run(): epochs = 2 history = model.fit(X_train, y_train, epochs=epochs, \\ validation_data=(scaler.transform(X_val),y_val), \\ verbose = True, class_weight = class_weights) y_pred_temp = model.predict(scaler.transform(X_test)) threshold = 0.995 y_pred = np.where(y_pred_temp &gt; threshold, 1,0) c_matrix = confusion_matrix(y_test,y_pred) ax = sns.heatmap(c_matrix, annot=True, cbar=False, cmap=&#39;Blues&#39;) ax.set_xlabel(&#34;Prediction&#34;) ax.set_ylabel(&#34;Actual&#34;) ax.set_title(&#39;Confusion Matrix&#39;) plt.show() t_n, f_p, f_n, t_p = c_matrix.ravel() mlflow.log_metric(&#34;tn&#34;, t_n) mlflow.log_metric(&#34;fp&#34;, f_p) mlflow.log_metric(&#34;fn&#34;, f_n) mlflow.log_metric(&#34;tp&#34;, t_p) model_proto,_ = tf2onnx.convert.from_keras(model) mlflow.onnx.log_model(model_proto, &#34;models&#34;) with mlflow.start_run(): is used to tell MLFlow to start a run, and it contains our training code to define exactly what code belongs to the &#34;run&#34;. Most of the rest of the code in this cell is normal model training and evaluation code, but at the bottom ar calls to send specific custom metrics to MLFlow through mlflow.log_metric() and then convert the model to ONNX. This is because ONNX is one of the standard formats for Red Hat OpenShift AI Model Serving which will be used later.
+Next run all the cells in the notebook from top to bottom, either by clicking Shift-Enter on every cell, or by going to Run→Run All Cells in the very top menu. If everything is set up correctly it will train the model and push both the run and the model to MLFlow. The run is a record with metrics of how the run went, while the model is the actual tensorflow and ONNX model which will be used later for inference. There may be some warning messages in the last cell related to MLFlow, as long as the final progress bar appears for the model being pushed to MLFlow all is fine:
+Figure 2. The trained model View the model in MLFlow Take a look at how the model looks inside MLFlow now that it has been trained. Open the MLFlow UI from the shortcut.
+Figure 3. View the trained model in MLFlow The Full Path of the model is required in the next section in order to serve the model. So keep the MLflow DNN-credit-card-fraud dialog open.
+Figure 4. MLFlow Model Path Serve the model The model can be served using Red Hat OpenShift AI Model Serving or by using the model directly from MLFlow. This section shows how you serve it with Red Hat OpenShift AI Model Serving, as it scales better for large applications and load. The bottom of this section goes through how to use MLFlow instead. To start, go to your Red Hat OpenShift AI Project and click &#34;Add data connection&#34;. This data connection connects to storage from where the model can be loaded.
+Figure 5. Add data connection Some details need to be added for the data connection. Assuming that you set up MLFlow according to this guide and have it connected to Red Hat Open Data Foundation. If that’s not the case then enter the relevant details for your usecase. Copy the code section below and run it all to find your values.
+echo &#34;==========Data connections Start===========&#34; echo &#34;Name \\nmlflow-connection&#34; echo echo AWS_ACCESS_KEY_ID oc get secrets mlflow-server -n mlops -o json | jq -r &#39;.data.AWS_ACCESS_KEY_ID|@base64d&#39; echo echo AWS_SECRET_ACCESS_KEY oc get secrets mlflow-server -n mlops -o json | jq -r &#39;.data.AWS_SECRET_ACCESS_KEY|@base64d&#39; echo echo AWS_S3_ENDPOINT oc get configmap mlflow-server -n mlops -o go-template --template=&#39;http://{{.data.BUCKET_HOST}}{{println}}&#39; echo echo &#34;AWS_DEFAULT_REGION \\nus-east-2&#34; echo echo AWS_S3_BUCKET oc get configmap mlflow-server -n mlops -o go-template --template=&#39;{{.data.BUCKET_NAME}}{{println}}&#39; echo echo &#34;Connected workbench \\nCredit Fraud Model&#34; echo &#34;==========Data connections End===========&#34; After pressing the &#34;Add data connection&#34; button. Here is an example of how to fill the form out:
+Figure 6. Add data connection details Next, configure a model server, which will serve our models.
+Figure 7. Configure model server Add Model Server Model server name = credit card fraud
+Serving runtime = OpenVINO Model Server
+Model server replicas = 1
+Model server size = Small
+Check the Make deployed models available through an external route box external access model is required. This is not needed in this dmeo.
+Deploy Model Finally, we will deply the model, to do that, press the &#34;Deploy model&#34; button which is in the same place that &#34;Configure Model&#34; was before. We need to fill out a few settings here:
+Name: credit card fraud
+Model framework: onnx-1 - Since we saved the model as ONNX in the model training section
+Model location:
+Name: mlflow-connection
+*Folder path: This is the full path we can see in the MLFlow interface from the end of the previous section. In my case it’s 1/b86481027f9b4b568c9efa3adc01929f/artifacts/models.Beware that we only need the last part, which looks something like: 1/…​./artifacts/models
+Note: use models not model. There are 2 folder in MLflow that might cause confusion.
+Figure 8. Review MLFlow Model Path Note the models in highlighted folder.
+Figure 9. Deploy the Model Press Deploy and wait for it to complete. A green checkmark will be displayed when done. The status is displayed on the line for model &#34;credit fraud&#34; to the right.
+Access the model application The model application is a visual interface for interacting with the model. You can use it to send data to the model and get a prediction of whether a transaction is fraudulent or not. It is deployed in inferencing-app project. You can access the model application from the images::grid.png short-cut on top right in openshift console: &#34;Inferencing App&#34;
+Check the INFERENCE_ENDPOINT env variable value. Go to https://&lt;your-uri&gt;/ns/inferencing-app/deployments/credit-fraud-detection-demo/environment. Make sure correct INFERENCE_ENDPOINT value is set. In this case it is http://modelmesh-serving.credit-fraud-model:8008/v2/models/credit-card-fraud/infer
+You can get this value from Value: In the RHODS projects interface (from the previous section), copy the &#34;restURL&#34; and add /v2/models/credit-card-fraud/infer to the end if it’s not already there. For example: http://modelmesh-serving.credit-card-fraud:8008/v2/models/credit-card-fraud/infer
+Congratulations, you now have an application running your AI model!
+Try entering a few values and see if it predicts it as a credit fraud or not. You can select one of the examples at the bottom of the application page.
+Next Steps Help &amp; Feedback Report Bugs
+`,url:"https://validatedpatterns.io/patterns/mlops-fraud-detection/mfd-running-the-demo/",breadcrumb:"/patterns/mlops-fraud-detection/mfd-running-the-demo/"},"https://validatedpatterns.io/learn/about-pattern-tiers-types/":{title:"Validated Pattern tiers",tags:[],content:` Validated Patterns tiers The different tiers of Validated Patterns 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.
+Icon Pattern tier Description Validated Patterns Sandbox tier
+A pattern categorized under the sandbox tier provides you with an entry point to onboard to Validated Patterns. The minimum requirement to qualify for the sandbox tier is to start with the patterns framework and include minimal documentation.
+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.
+Validated Patterns Tested tier
+A pattern categorized under the tested tier implies that the pattern might have been recently working on at least one recent version of Red Hat OpenShift Container Platform. Qualifying for this tier might require additional work for the pattern’s owner, who might be a partner or a motivated subject matter expert (SME).
+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 Red Hat OpenShift Container Platform minor version.
+Validated Patterns Maintained tier
+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 Red Hat OpenShift Container Platform. Qualifying for this tier might require additional work for the pattern’s owner who might be a partner or a motivated SME.
+The patterns in this tier might have a formal release process with patch releases. They might have continuous integration (CI) automation testing.
+`,url:"https://validatedpatterns.io/learn/about-pattern-tiers-types/",breadcrumb:"/learn/about-pattern-tiers-types/"},"https://validatedpatterns.io/contribute/background-on-pattern-development/":{title:"Background on pattern development",tags:[],content:` Introduction This section provides details on how to create a new pattern using the validated patterns framework. Creating a new pattern might start from scratch or it may start from an existing deployment that would benefit from a repeatable framework based on GitOps.
+This introduction explains some of framework design decisions and why they were chosen. There are some high level concepts that are required for the framework. While those concepts can be implemented using a variety of open source projects, this framework is prescriptive and mentions the project and also (down stream) product that was used. E.g. For development builds we use Tekton (project) and specifically use OpenShift Pipelines (product).
+The framework uses popular Cloud Native Computing Foundation (CNCF) projects as much as possible. The CNCF landscape contains many projects that solve the same or similar problem. The validated patterns effort has chosen specific projects but it is not unreasonable for users to switch out one project for another. (See more on Operators below).
+There is no desire to replicate efforts already in CNCF. If new a open source project comes out of this framework, the plan would be to contribute that to CNCF.
+Who is a pattern developer? Many enterprise class Cloud Native applications are complex and require many different application services integrated together. Organizations can learn from each other on how to create robust, scalable, and maintainable systems. When you find a pattern that seems to work, it makes sense to promote best practices to others in order for them to not repeat the many failures you probably made while getting to your killer pattern.
+In the world of DevOps (including DevSecOps and GitOps), teams should include personnel from development, operations, security, and architects. What makes DevOps work is the collaboration of all these IT personnel, the business owners, and others. As DevOps practices move through your organization, best practices are shared and standards evolve.
+This validated patterns framework has evolved since it was started in 2019. It will likely continue to evolve. What was learned is that there are some common concepts that need to be addressed once you desire to generalize your organizations framework.
+Therefore, the goal is, that developers, operators, security, and architects will use this framework to have secure and repeatable day one deployment mechanism and maintenance automation for day two operations.
+A common platform One of the most important goals of this framework is to provide consistency across any cloud provider - public or private. Public cloud providers each have Kubernetes distributions. While they keep up with the Kubernetes release cycle, they are not always running on the same version. Furthermore, each cloud provider has their own sets of services that developers often consume. So while you could automate the handling for each of the cloud providers, the framework utilizes one Kubernetes distribution that runs on public or private clouds - the hybrid and/or multi cloud model.
+The framework depends on Red Hat OpenShift Container Platform (OCP). Once you have deployed Red Hat OCP wherever you wish to deploy your cloud native application pattern, then the framework can deploy on that platform in a few easy steps.
+Containment beyond containers If you are reading this chances are you are already familiar with Linux containers. But there is more to containers than Linux containers in the Cloud Native environment.
+Containers Containers allow you to encapsulate your program/process and all its dependencies in one package called a container image. The container runtime starts an instance of this container using only the Linux kernel and the directory structure, with program and dependencies, provided in the container image. This ensures that the program is running isolated from any other packages, programs, or files loaded on the host system.
+Kubernetes, and the Cloud Native community of services, use Linux containers as their basic building block.
+Operators While Linux containers provide an incredibly useful way to isolate the dependencies for an application or application service, containers also require some lifecycle management. For example, at start up a container my need to set up access to networks, or extra storage. This type of set up usually happens with a human operator deciding on how the container will connect networks or host storage. The operator may also have to do routine maintenance. For example, if the container contains a database, the human operator may need to do a backup or routine scrubbing of the database.
+Kubernetes Operators are an extension to Kubernetes &#34;that make sue of custom resources to manage applications and their components.&#34; I.e. it provides an extra layer of encapsulation on top of containers that packages up some operation automation with the container. It puts what the human operator would do into an Operator pattern for the service or set of services.
+Many software providers/vendors have created operators to manage their application or service lifecycle. Red Hat OpenShift provides a catalog of certified Operators that application develops can consume as part of their overall application. The validated patterns makes use of these certified Operators as much as possible. Having a common platform like Red Hat OpenShift helps reduce risk by using certified Operators.
+Validated patterns Assembling operators into a common pattern provides another layer of encapsulation. As with an Operator, where the developer can take advantage of the best practices from a experienced human operator, a validated pattern provides a way of taking advantage of best practices for deploying operators and other assets for a particular type of solution. Rather than starting from scratch to figure out how to deploy and manage a complex set of integrated and dependent containerized services, a developer can take a validated pattern and know that a lot of experience has been put into it.
+A validated pattern has been tested and continues to be tested as the lifecycle of individual parts (Operators) change through release cycles. Red Hat’s Quality Engineering team provides Continuous Integration of the pattern for new releases of Red Hat products (Operators).
+The validated patterns framework takes advantage of automation technology. It uses Cloud Native automation technology as much as possible. Occasionally the framework resorts to some scripts in order to get a pattern up and running faster.
+Automation has many layers As mentioned above, gaining consistency and robustness for deploying complex Cloud Native applications requires automation. While many Kubernetes distributions, including OpenShift, provide excellent user interfaces for deploying and managing applications, this is mostly useful during development and/or debugging when things go wrong. Being able to consistently deploy complex applications is critical.
+But which automation tool should be used? Or which automation tools, plural? During the development of the validated patterns framework we learned important lessons on the different areas of automation.
+Automation for building application code When developing container based Cloud Native applications, a developer needs to build executable code and create a new container image for deployment into their Kubernetes test environment. Once tested, that container image needs to be moved through the continuous integration and continuous deployment (CI/CD) pipeline until it ends up in production. Tekton is a Cloud Native CI/CD project that is build for hybrid-cloud. OpenShift Pipelines is a Red Hat product based on Tekton.
+Automation for application operations There are two aspects to consider for operations when doing automation. First, you must be able to package up much of the configuration that is required for deploying Operators and pods. The validated patterns framework started with a project called Kustomize which allows you to assemble complex deployment YAML to apply to your Kubernetes cluster. Kustomize is a powerful tool, and almost achieved what we needed. However it fell short when we needed to propagate variable data into our deployment YAML. Instead we chose Helm because it provides templating and can therefore handle the injection of variable data into the deployment package. See more on templating here.
+The second aspect of automation for application automation deals with both workflow and GitOps. Validated patterns requires that a workflow deploys various components of the complex application. Visibility into the success or failure of those application components is really important. After the initial deployment it is important to role out configuration changes in an automated way using a code repository. This is achieved using GitOps. I.e. Using a Git repository as a mechanism to change configuration that triggers the automatic roll-out of those changes.
+&#34;Application definitions, configurations, and environments should be declarative and version controlled. Application deployment and lifecycle management should be automated, auditable, and easy to understand.&#34; - Argo CD project
+OpenShift GitOps is based on the Argo CD project. It is a GitOps continuous delivery tool for Kubernetes.
+Secret handling Validated patterns often depend on resources that require certificates or keys. These secrets need to be handled carefully. While it’s tempting to focus on just the deployment of a pattern and &#34;handle security later&#34;, that’s a bad idea. In the spirit of DevSecOps, the validated patterns effort has decided to &#34;shift security left&#34;. I.e. build security in early in the lifecycle.
+When it comes to security, the approach requires patience and care to set up. There is no avoiding some manual steps but validated patterns tries to automate as much as possible while at the same time taking the lid off so developers can see what was and needs to be done.
+There are two approaches to secret handling with validated patterns:
+Using special configuration files. This is fine for initial development but not for production.
+Using a Cloud Native secrets handling tool e.g. Vault or Conjur
+Some of the validated patterns use configuration files (for now), while others, like the Multicloud GitOps, use Vault. See Vault Setup for more info.
+Policy While many enterprise Cloud Native applications are open source, many of the products used require licenses or subscriptions. Policies help enforce license and subscription management and the channels needed to get access to those licenses or subscriptions.
+Similarly, in multicloud deployments and complex edge deployments, policies can help define and select the correct GitOps workflows that need to be managed for various sites or clusters. E.g. defining an OpenShift Cluster as a &#34;Factory&#34; in the Industrial Edge validated pattern provides a simple trigger to roll-out the entire Factory deployment. Policy is a powerful tool in automation.
+Validated patterns use Red Hat Advanced Cluster Management for Kubernetes to control clusters and applications from a single console, with built-in security policies.
+`,url:"https://validatedpatterns.io/contribute/background-on-pattern-development/",breadcrumb:"/contribute/background-on-pattern-development/"},"https://validatedpatterns.io/patterns/medical-diagnosis-amx/cluster-sizing/":{title:"Cluster Sizing",tags:[],content:` About OpenShift cluster sizing for the Intel AMX accelerated Medical Diagnosis pattern The minimum requirements for an OpenShift Container Platform cluster depend on your installation platform, for example:
+For AWS, see Installing OpenShift Container Platform on AWS.
+For bare-metal, see Installing OpenShift Container Platform on bare metal.
+To understand cluster sizing requirements for the Intel AMX accelerated Medical Diagnosis pattern, consider the following components that the Intel AMX accelerated Medical Diagnosis pattern deploys on the datacenter or the hub OpenShift cluster:
+Name Kind Namespace Description Medical Diagnosis Hub
+Application
+medical-diagnosis-hub
+Hub GitOps management
+Red Hat OpenShift GitOps
+Operator
+openshift-operators
+OpenShift GitOps
+Red Hat OpenShift Data Foundation
+Operator
+openshift-storage
+Cloud Native storage solution
+Red Hat AMQ Streams
+Operator
+openshift-operators
+AMQ Streams provides Apache Kafka access
+Red Hat OpenShift Serverless
+Operator
+- knative-serving (knative-eventing)
+Provides access to Knative Serving and Eventing functions
+Node Feature Discovery Operator
+Operator
+openshift-nfd
+Manages the detection and labeling of hardware features and configuration (for example Intel AMX)
+The Intel AMX accelerated Medical Diagnosis pattern also includes the Red Hat Advanced Cluster Management (RHACM) supporting operator that is installed by OpenShift GitOps using Argo CD.
+For information about requirements for additional platforms, see OpenShift Container Platform documentation.
+About Intel AMX accelerated Medical Diagnosis pattern OpenShift cluster size The OpenShift cluster is a standard deployment of 3 control plane nodes and 3 or more worker nodes.
+The recommended hardware setup:
+Node type Number of nodes CPU Memory Storage Control Planes
+3
+2x 5th Generation Intel Xeon Gold 6526Y (16 cores at 2.8 GHz base with Intel AMX) or better
+128 GB (8 x 16 GB DDR5 4800) or more
+NVME SSD 3TB or more
+Workers
+3
+2x 5th Generation Intel Xeon Gold 6538Y+ (32 cores at 2.2 GHz base with Intel AMX) or better
+256 GB (16 x 16 GB) or 512 GB (16 x 32GB) DDR5-4800
+NVME SSD 3TB or more
+You might want to add resources when more developers are working on building their applications.
+The pattern was tested in the on-premises environment with following hardware configuration (per cluster):
+Node type Number of nodes CPU Memory Storage Control Planes + Workers
+3 + 3
+2x 5th Generation Intel Xeon Platinum 8568Y+ (48 cores at 2.3 GHz base with Intel AMX)
+512 GB (16x32GB DDR5 5600)
+4x 3.84TB U.2 NVMe PCIe Gen4
+`,url:"https://validatedpatterns.io/patterns/medical-diagnosis-amx/cluster-sizing/",breadcrumb:"/patterns/medical-diagnosis-amx/cluster-sizing/"},"https://validatedpatterns.io/patterns/medical-diagnosis/cluster-sizing/":{title:"Cluster Sizing",tags:[],content:` About OpenShift cluster sizing for the Medical Diagnosis pattern To understand cluster sizing requirements for the Medical Diagnosis pattern, consider the following components that the Medical Diagnosis pattern deploys on the datacenter or the hub OpenShift cluster:
+Name Kind Namespace Description Medical Diagnosis Hub
+Application
+medical-diagnosis-hub
+Hub GitOps management
+Red Hat OpenShift GitOps
+Operator
+openshift-operators
+OpenShift GitOps
+Red Hat OpenShift Data Foundation
+Operator
+openshift-storage
+Cloud Native storage solution
+Red Hat AMQ Streams
+Operator
+openshift-operators
+AMQ Streams provides Apache Kafka access
+Red Hat OpenShift Serverless
+Operator
+- knative-serving (knative-eventing)
+Provides access to Knative Serving and Eventing functions
+The minimum requirements for an OpenShift Container Platform cluster depend on your installation platform. For instance, for AWS, see Installing OpenShift Container Platform on AWS, and for bare-metal, see Installing OpenShift Container Platform on bare metal.
+For information about requirements for additional platforms, see OpenShift Container Platform documentation.
+About Medical Diagnosis pattern OpenShift cluster size The Medical Diagnosis pattern has been tested with a defined set of configurations that represent the most common combinations that OpenShift Container Platform customers are using for the x86_64 architecture.
+For Medical Diagnosis pattern, the OpenShift cluster size must be a bit larger to support the compute and storage demands of OpenShift Data Foundations and other Operators.
+You might want to add resources when more developers are working on building their applications.
+The OpenShift cluster is a standard deployment of 3 control plane nodes and 3 or more worker nodes.
+Node type Number of nodes Cloud provider Instance type Control plane and worker
+3 and 3
+Google Cloud
+n1-standard-8
+Control plane and worker
+3 and 3
+Amazon Cloud Services
+m5.2xlarge
+Control plane and worker
+3 and 3
+Microsoft Azure
+Standard_D8s_v3
+Additional resource AWS instance types
+Azure instance types: Sizes for virtual machines in Azure
+Google Cloud Platform instance types: Machine families resource and comparison guide
+`,url:"https://validatedpatterns.io/patterns/medical-diagnosis/cluster-sizing/",breadcrumb:"/patterns/medical-diagnosis/cluster-sizing/"},"https://validatedpatterns.io/patterns/industrial-edge/factory/":{title:"Factory Sites",tags:[],content:`Having a factory (edge) cluster join the datacenter (hub) Allow ACM to deploy the factory application to a subset of clusters By default the factory applications are deployed on all clusters that ACM knows about.
+managedSites: - name: factory clusterSelector: matchExpressions: - key: vendor operator: In values: - OpenShift This is useful for cost-effective demos, but is hardly realistic.
+To deploy the factory applications only on managed clusters with the label site=factory, change the site definition in values-datacenter.yaml to:
+managedSites: - name: factory clusterSelector: matchLabels: site: factory Remember to commit the changes and push to GitHub so that GitOps can see your changes and apply them.
+Deploy a factory cluster For instructions on how to prepare and import a factory cluster please read the section importing a cluster. Use clusterGroup=factory.
+You&rsquo;re done That&rsquo;s it! Go to your factory (edge) OpenShift console and check for the open-cluster-management-agent pod being launched. Be patient, it will take a while for the ACM agent and agent-addons to launch. After that, the operator OpenShift GitOps will run. When it&rsquo;s finished coming up launch the OpenShift GitOps (ArgoCD) console from the top right of the OpenShift console.
+Next up Work your way through the Industrial Edge 2.0 GitOps/DevOps demos
+`,url:"https://validatedpatterns.io/patterns/industrial-edge/factory/",breadcrumb:"/patterns/industrial-edge/factory/"},"https://validatedpatterns.io/patterns/rag-llm-gitops/gpu_provisioning/":{title:"GPU provisioning",tags:[],content:`GPU provisioning Use the instructions to add nodes with GPU in OpenShift cluster running in AWS cloud. Nodes with GPU will be tainted to allow only pods that required GPU to be scheduled to these nodes
+More details can be found in following documents Openshift AI, NVIDIA on OpenShift
+Add machineset The easiest way is to use existing machineset manifest and update certain elements. Use worker machineset manifest and modify some of the entries (naming conventions provided as reference only, use own if required.), keep other entries as is:
+apiVersion: machine.openshift.io/v1beta1 kind: MachineSet metadata: name: &lt;clustername&gt;-gpu-&lt;AWSregion&gt; .............. spec: replicas: 1 selector: matchLabels: ................ machine.openshift.io/cluster-api-machineset: &lt;clustername&gt;-gpu-&lt;AWSregion&gt; template: metadata: labels: ........ machine.openshift.io/cluster-api-machineset: &lt;clustername&gt;-gpu-&lt;AWSregion&gt; spec: ................... metadata: labels: node-role.kubernetes.io/odh-notebook: &#39;&#39; &lt;--- Put your label if needed providerSpec: value: ........................ instanceType: g5.2xlarge &lt;---- Change vm type if needed ............. taints: - effect: NoSchedule key: odh-notebook &lt;--- Use own taint name or skip all together value: &#39;true&#39; Use kubectl or oc command line to create new machineset oc apply -f gpu_machineset.yaml
+Depending on type of EC2 instance creation of the new machines make take some time. Please note that all nodes with GPU will have labels(node-role.kubernetes.io/odh-notebookin our case) and taints (odh-notebook ) that we have specified in machineset applied automatically
+Install Node Feature Operator From OperatorHub install Node Feature Discovery Operator , accepting defaults . Once Operator has been installed , create NodeFeatureDiscoveryinstance . Use default entries unless you something specific is needed . Node Feature Discovery Operator will add labels to nodes based on available hardware resources
+Install NVIDIA GPU Operator NVIDIA GPU Operator will provision daemonsets with drivers for the GPU to be used by workload running on these nodes . Detailed instructions are available in NVIDIA Documentation NVIDIA on OpenShift . Following simplified steps for specific setup :
+Install NVIDIA GPU Operator from OperatorHub Once operator is ready create ClusterPolicy custom resource. Unless required you can use default settings with adding tolerations if machineset in first section has been created with taint. Failing to add tolerations will prevent drivers to be installed on GPU enabled node : apiVersion: nvidia.com/v1 kind: ClusterPolicy metadata: name: gpu-cluster-policy spec: vgpuDeviceManager: enabled: true migManager: enabled: true operator: defaultRuntime: crio initContainer: {} runtimeClass: nvidia use_ocp_driver_toolkit: true dcgm: enabled: true gfd: enabled: true dcgmExporter: config: name: &#39;&#39; enabled: true serviceMonitor: enabled: true driver: certConfig: name: &#39;&#39; enabled: true kernelModuleConfig: name: &#39;&#39; licensingConfig: configMapName: &#39;&#39; nlsEnabled: false repoConfig: configMapName: &#39;&#39; upgradePolicy: autoUpgrade: true drain: deleteEmptyDir: false enable: false force: false timeoutSeconds: 300 maxParallelUpgrades: 1 maxUnavailable: 25% podDeletion: deleteEmptyDir: false force: false timeoutSeconds: 300 waitForCompletion: timeoutSeconds: 0 virtualTopology: config: &#39;&#39; devicePlugin: config: default: &#39;&#39; name: &#39;&#39; enabled: true mig: strategy: single sandboxDevicePlugin: enabled: true validator: plugin: env: - name: WITH_WORKLOAD value: &#39;false&#39; nodeStatusExporter: enabled: true daemonsets: rollingUpdate: maxUnavailable: &#39;1&#39; tolerations: - effect: NoSchedule key: odh-notebook value: &#39;true&#39; updateStrategy: RollingUpdate sandboxWorkloads: defaultWorkload: container enabled: false gds: enabled: false vgpuManager: enabled: false vfioManager: enabled: true toolkit: enabled: true installDir: /usr/local/nvidia Provisioning NVIDIA daemonsets and compiling drivers may take some time (5-10 minutes)
+`,url:"https://validatedpatterns.io/patterns/rag-llm-gitops/gpu_provisioning/",breadcrumb:"/patterns/rag-llm-gitops/gpu_provisioning/"},"https://validatedpatterns.io/patterns/multicloud-gitops-amx-rhoai/mcg-amx-rhoai-demo-script/":{title:"Hello-world Demo",tags:[],content:` Introduction The multicloud gitops pattern is designed to be an entrypoint into the Validated Patterns framework. Demo, accessible within the pattern, contains two applications config-demo and hello-world to show the basic configuration and execution examples. For more information on Validated Patterns visit our documentation site.
+Objectives In this demo you will complete the following:
+Prepare your local workstation
+Deploy the pattern
+Extend the pattern with a small tweak
+Getting Started Make sure you have met all the installation prerequisites
+Follow the Getting Started Guide to ensure that you have met all of the prerequisites
+This demo begins after ./pattern.sh make install has been executed
+Demo Now that we have deployed the pattern onto our cluster, with origin pointing to your fork and using my-branch as the name of the used branch, we can begin to discover what has happened. You should be able to click on the nine-box and see the following entries:
+If you now click on the &#34;Hub ArgoCD&#34; menu entry you will be taken to the ArgoCD instance with all the applications.
+Secrets loading With pattern.sh script By default in the MultiCloud GitOps pattern the secrets get loaded automatically via an out of band process inside the vault running in the OCP cluster. This means that running ./pattern.sh make install will also call the load-secrets makefile target. This load-secrets target will look for a yaml file describing the secrets to be loaded into vault and in case it cannot find one it will use the values-secret.yaml.template file in the git repo to try and generate random secrets.
+Let’s copy the template to our home folder and reload the secrets:
+cp ./values-secret.yaml.template ~/values-secret-multicloud-gitops.yaml ./pattern.sh make load-secrets At this point if the config-demo application was not green already it should become green in the ArgoCD user interface.
+Manually Another way to load secrets is to add them for config-demo application (from values-secret-multicloud-gitops.yaml) to Vault manually:
+Go to Vault service route. URL can be found:
+by running command:
+oc -n vault get route vault -ojsonpath=&#39;{.spec.host}&#39; in Openshift Container Platform web console under Networking &gt; Routes for vault project.
+Log into the Vault using root token. Root token can be found by executing command:
+oc -n imperative get secrets vaultkeys -ojsonpath=&#39;{.data.vault_data_json}&#39; | base64 -d After login go to secret catalog and clik Create secret and fill all the fields manually:
+Put global/config-demo value in the Path for this secret field (the value comes from values-secret-multicloud-gitops.yaml file).
+Add one Secret data key-value pair. Put secret as a key (left field) and required value (right field). Click Add button to confirm.
+Click Save to save changes.
+Verify the test web pages If you now click on the Routes in the Networking menu entry you will see the following network routes:
+Clicking on the hello-world application should show a small demo app that prints &#34;Hello World!&#34;:
+Once the secrets are loaded correctly inside the vault, clicking on the config-demo route should display a small application where said secret is shown:
+Make a small change to the test web pages Now we can try and tweak the hello-world application and add the below line in the charts/all/hello-world/templates/hello-world-cm.yaml file:
+diff --git a/charts/all/hello-world/templates/hello-world-cm.yaml b/charts/all/hello-world/templates/hello-world-cm.yaml index e59561ca..bd416bc6 100644 --- a/charts/all/hello-world/templates/hello-world-cm.yaml +++ b/charts/all/hello-world/templates/hello-world-cm.yaml @@ -14,6 +14,7 @@ data: &lt;/head&gt; &lt;body&gt; &lt;h1&gt;Hello World!&lt;/h1&gt; + &lt;h1&gt;This is a patched version via git&lt;/h1&gt; &lt;br/&gt; &lt;h2&gt; Hub Cluster domain is &#39;{{ .Values.global.hubClusterDomain }}&#39; &lt;br&gt; Once we commit the above change via git commit -a -m &#34;test a change&#34; and run git push origin my-branch we will be able to observe argo applying the above change:
+Summary You did it! You have completed the deployment of the MultiCloud GitOps pattern and you made a small local change and applied it via GitOps! Hopefully you are getting ideas of how you can take advantage of our GitOps framework to deploy and manage your applications.
+For more information on Validated Patterns visit our website
+`,url:"https://validatedpatterns.io/patterns/multicloud-gitops-amx-rhoai/mcg-amx-rhoai-demo-script/",breadcrumb:"/patterns/multicloud-gitops-amx-rhoai/mcg-amx-rhoai-demo-script/"},"https://validatedpatterns.io/patterns/ansible-edge-gitops-kasten/installation-details/":{title:"Installation Details",tags:[],content:`Installation Details Installation Steps These are the steps run by make install and what each one does:
+operator-deploy The operator-deploy task installs the Validated Patterns Operator, which in turn creates a subscription for the OpenShift GitOps operator and installs both the cluster and hub instances of it. The clustergroup application will then read the values-global.yaml and values-hub.yaml files for other subscriptions and applications to install.
+The legacy-install is still provided for users that cannot or do not want to use the Validated Patterns operator. Instead of installing the operator, it installs a helm chart that does the same thing - installs a subscription for OpenShift GitOps and installs a cluster-wide and hub instance of that operator. It then proceeds with installing the clustergroup application.
+Note that both the upgrade and legacy-upgrade targets are now equivalent and interchangeable with install and legacy-install (respectively - legacy-install/legacy-upgrade are not compatible with standard install/upgrade. This was not always the case, so both install/upgrade targets are still provided).
+Imperative section Part of the operator-deploy process is creating and running the imperative tools as defined in the hub values file. In this pattern, that includes running the playbook to deploy the metal worker.
+The real code for this playbook (outside of a shell wrapper) is here.
+This script is another Ansible playbook that deploys a node to run the Virtual Machines for the demo. The playbook uses the OpenShift machineset API to provision the node in the first availability zone it finds. Currently, AWS is the only major public cloud provider that offers the deployment of a metal node through the normal provisioning process. We hope that Azure and GCP will support this functionality soon as well.
+Please be aware that the metal node is rather more expensive in compute costs than most other AWS machine types. The trade-off is that running the demo without hardware acceleration would take ~4x as long.
+It takes about 20-30 minutes for the metal node to become available to run VMs. If you would like to see the current status of the metal node, you can check it this way (assuming your kubeconfig is currently set up to point to your cluster):
+oc get -A machineset You will be looking for a machineset with metal-worker in its name:
+NAMESPACE NAME DESIRED CURRENT READY AVAILABLE AGE openshift-machine-api mhjacks-aeg-qx25w-metal-worker-us-west-2a 1 1 1 1 19m openshift-machine-api mhjacks-aeg-qx25w-worker-us-west-2a 1 1 1 1 47m openshift-machine-api mhjacks-aeg-qx25w-worker-us-west-2b 1 1 1 1 47m openshift-machine-api mhjacks-aeg-qx25w-worker-us-west-2c 1 1 1 1 47m openshift-machine-api mhjacks-aeg-qx25w-worker-us-west-2d 0 0 47m When the metal-worker is showing &ldquo;READY&rdquo; and &ldquo;AVAILABLE&rdquo;, the virtual machines will begin provisioning on it.
+The metal node will be destroyed when the cluster is destroyed. The script is idempotent and will create at most one metal node per cluster.
+post-install Note that all the steps of post-install are idempotent. If you want or need to reconfigure vault or AAP, the recommended way to do so is to call make post-install. This may change as we move elements of this pattern into the new imperative framework in common.
+Specific processes that are called by post-install include:
+vault-init Vault requires extra setup in the form of unseal keys and configuration of secrets. The vault-init task does this. Note that it is safe to run vault-init as it will exit successfully if it can connect to a cluster with a running, unsealed vault.
+load-secrets This process (which calls push_secrets) calls an Ansible playbook that reads the values-secret.yaml file and stores the data it finds there in vault as keypairs. These values are then usable in the kubernetes cluster. This pattern uses the ssh pubkey for the kiosk VMs via the external secrets operator.
+This script will update secrets in vault if re-run; it is safe to re-run if the secret values have not changed as well.
+configure-controller There are two parts to this script - the first part, with the code here, retrieves the admin credentials from OpenShift to enable login to the AAP Controller.
+The second part, which is the bulk of the ansible-load-controller process is here and uses the controller configuration framework to configure the Ansible Automation Platform instance that is installed by the helm chart.
+This division is so that users can adapt this pattern more easily if they&rsquo;re running AAP, but not on OpenShift.
+The script waits until AAP is ready, and then proceeds to:
+Install the manifest to entitle AAP Configure the custom Credential Types the demo needs Define an Organization for the Demo Add a Project for the Demo Add the Credentials for jobs to use Configure Host inventory and inventory sources, and smart inventories to define target hosts Configure an Execution environment for the Demo Configure Job Templates for the Demo Configure Schedules for the jobs that need to repeat Note: This script has defaults that it overrides when run as part of make install that it derives from the environment (the repo that it is attached to and the branch that it is on). So if you need to re-run it, the most straightforward way to do this is to run make upgrade when using the make-based installation process.
+OpenShift GitOps (ArgoCD) OpenShift GitOps is central to this pattern as it is responsible for installing all of the other components. The installation process is driven through the installation of the clustergroup chart. This in turn reads the repo&rsquo;s global values file, which instructs it to read the hub values file. This is how the pattern knows to apply the Subscriptions and Applications listed further in the pattern.
+ODF (OpenShift Data Foundations) ODF is the storage framework that is needed to provide resilient storage for OpenShift Virtualization. It is managed via the helm chart here. This is basically the same chart that our Medical Diagnosis pattern uses (see here for details on the Medical Edge pattern&rsquo;s use of storage).
+Please note that this chart will create a Noobaa S3 bucket named nb.epoch_timestamp.cluster-domain which will not be destroyed when the cluster is destroyed.
+OpenShift Virtualization (KubeVirt) OpenShift Virtualization is a framework for running virtual machines as native Kubernetes resources. While it can run without hardware acceleration, the performance of virtual machines will suffer terribly; some testing on a similar workload indicated a 4-6x delay running without hardware acceleration, so at present this pattern requires hardware acceleration. The pattern provides a script deploy-kubevirt-worker.sh which will provision a metal worker to run virtual machines for the pattern.
+OpenShift Virtualization currently supports only AWS and on-prem clusters; this is because of the way that baremetal resources are provisioned in GCP and Azure. We hope that OpenShift Virtualization can support GCP and Azure soon.
+The installation of the OpenShift Virtualization HyperConverged deployment is controlled by the chart here.
+OpenShift Virtualization was chosen in this pattern to avoid dealing with the differences in galleries and templates of images between the different public cloud providers. The important thing from this pattern&rsquo;s standpoint is the availability of machine instances to manage (since we are simulating an Edge deployment scenario, which could either be bare metal instances or virtual machines); OpenShift Virtualization was the easiest and most portable way to spin up machine instances. It also provides mechanisms for defining the desired machine set declaratively.
+The creation of virtual machines is controlled by the chart here.
+More details about the way we use OpenShift Virtualization are available here.
+Ansible Automation Platform (AAP, formerly known as Ansible Tower) The use of Ansible Automation Platform is really the centerpiece of this pattern. We have recognized for some time that the notion and design principles of GitOps should apply to things outside of Kubernetes, and we believe this pattern gives us a way to do that.
+All of the Ansible interactions are defined in a Git Repository; the Ansible jobs that configure the VMs are designed to be idempotent (and are scheduled to run every 10 minutes on those VMs).
+The installation of AAP itself is governed by the chart here. The post-installation configuration of AAP is done via the ansible-load-controller.sh script.
+It is very much the intention of this pattern to make it easy to replace the specific Edge management use case with another one. Some ideas on how to do that can be found here.
+Specifics of the Ansible content for this pattern can be seen here.
+More details of the specifics of how AAP is configured are available here.
+Veeam Kasten As VMs are inherently stateful workloads, a GitOps approach alone is not sufficient to recover an environment in the event of accidental data loss, malware attack, or infrastructure failure - especially in edge environments where infrastructure may be less resilient or subject to harsh environments. This example extends the standard Ansible Edge GitOps pattern to include automated deployment and configuration of Veeam Kasten, the #1 Kubernetes data protection and mobility solution.
+The addition of Veeam Kasten is implemented by the following components:
+Deployment of the Veeam Kasten operator into the kasten-io namespace via the OperatorHub, as configured in values-hub.yaml Deployment of an instance of Veeam Kasten (K10 operand) via chart-based ArgoCD Application, as configured in charts/hub/veeam-kasten The example instance configures a Route for Dashboard access and integrates with the cluster&rsquo;s OAuth server for authentication A complete list of available configuration parameters for the K10 operand (aka Helm values) can be found at docs.kasten.io Post-installation configuration of Veeam Kasten via chart-based ArgoCD Application, as configured in charts/hub/veeam-kasten-config Creates an AWS Location Profile for exporting backup data (uses the same values-secret.yaml aws-creds credentials to read from and write to the bucket configured in values-kasten-defaults.yaml) Enables the Kasten DR policy to protect the local catalog and configuration in the event of infrastructure failure/unavailability Creates an example Policy Preset to provide templates for future policies Adds required Kasten annotation to all available VolumeSnapshotClass resources Adds required Kasten annotation for enabling block exports to all StorageClass resources using either the openshift-storage.rbd.csi.ceph.com or ebs.csi.aws.com CSI provisioners Policy for protecting the edge-gitops-vms namespace added to the edge-gitops-vms chart-based ArgoCD application, as defined in egv-backup-policy.yaml Note that the policy could alternatively be included in the veeam-kasten-config Application, but as a general best practice the manifest for protecting a workload should be stored alongside the manifests for deploying the workload Next Steps Help &amp; Feedback Report Bugs `,url:"https://validatedpatterns.io/patterns/ansible-edge-gitops-kasten/installation-details/",breadcrumb:"/patterns/ansible-edge-gitops-kasten/installation-details/"},"https://validatedpatterns.io/patterns/ansible-edge-gitops/installation-details/":{title:"Installation Details",tags:[],content:`Installation Details Installation Steps These are the steps run by make install and what each one does:
+operator-deploy The operator-deploy task installs the Validated Patterns Operator, which in turn creates a subscription for the OpenShift GitOps operator and installs both the cluster and hub instances of it. The clustergroup application will then read the values-global.yaml and values-hub.yaml files for other subscriptions and applications to install.
+The legacy-install is still provided for users that cannot or do not want to use the Validated Patterns operator. Instead of installing the operator, it installs a helm chart that does the same thing - installs a subscription for OpenShift GitOps and installs a cluster-wide and hub instance of that operator. It then proceeds with installing the clustergroup application.
+Note that both the upgrade and legacy-upgrade targets are now equivalent and interchangeable with install and legacy-install (respectively - legacy-install/legacy-upgrade are not compatible with standard install/upgrade. This was not always the case, so both install/upgrade targets are still provided).
+Imperative section Part of the operator-deploy process is creating and running the imperative tools as defined in the hub values file. In this pattern, that includes running the playbook to deploy the metal worker.
+The real code for this playbook (outside of a shell wrapper) is here.
+This script is another Ansible playbook that deploys a node to run the Virtual Machines for the demo. The playbook uses the OpenShift machineset API to provision the node in the first availability zone it finds. Currently, AWS is the only major public cloud provider that offers the deployment of a metal node through the normal provisioning process. We hope that Azure and GCP will support this functionality soon as well.
+Please be aware that the metal node is rather more expensive in compute costs than most other AWS machine types. The trade-off is that running the demo without hardware acceleration would take ~4x as long.
+It takes about 20-30 minutes for the metal node to become available to run VMs. If you would like to see the current status of the metal node, you can check it this way (assuming your kubeconfig is currently set up to point to your cluster):
+oc get -A machineset You will be looking for a machineset with metal-worker in its name:
+NAMESPACE NAME DESIRED CURRENT READY AVAILABLE AGE openshift-machine-api mhjacks-aeg-qx25w-metal-worker-us-west-2a 1 1 1 1 19m openshift-machine-api mhjacks-aeg-qx25w-worker-us-west-2a 1 1 1 1 47m openshift-machine-api mhjacks-aeg-qx25w-worker-us-west-2b 1 1 1 1 47m openshift-machine-api mhjacks-aeg-qx25w-worker-us-west-2c 1 1 1 1 47m openshift-machine-api mhjacks-aeg-qx25w-worker-us-west-2d 0 0 47m When the metal-worker is showing &ldquo;READY&rdquo; and &ldquo;AVAILABLE&rdquo;, the virtual machines will begin provisioning on it.
+The metal node will be destroyed when the cluster is destroyed. The script is idempotent and will create at most one metal node per cluster.
+post-install Note that all the steps of post-install are idempotent. If you want or need to reconfigure vault or AAP, the recommended way to do so is to call make post-install. This may change as we move elements of this pattern into the new imperative framework in common.
+Specific processes that are called by post-install include:
+vault-init Vault requires extra setup in the form of unseal keys and configuration of secrets. The vault-init task does this. Note that it is safe to run vault-init as it will exit successfully if it can connect to a cluster with a running, unsealed vault.
+load-secrets This process (which calls push_secrets) calls an Ansible playbook that reads the values-secret.yaml file and stores the data it finds there in vault as keypairs. These values are then usable in the kubernetes cluster. This pattern uses the ssh pubkey for the kiosk VMs via the external secrets operator.
+This script will update secrets in vault if re-run; it is safe to re-run if the secret values have not changed as well.
+configure-controller There are two parts to this script - the first part, with the code here, retrieves the admin credentials from OpenShift to enable login to the AAP Controller.
+The second part, which is the bulk of the ansible-load-controller process is here and uses the controller configuration framework to configure the Ansible Automation Platform instance that is installed by the helm chart.
+This division is so that users can adapt this pattern more easily if they&rsquo;re running AAP, but not on OpenShift.
+The script waits until AAP is ready, and then proceeds to:
+Install the manifest to entitle AAP Configure the custom Credential Types the demo needs Define an Organization for the Demo Add a Project for the Demo Add the Credentials for jobs to use Configure Host inventory and inventory sources, and smart inventories to define target hosts Configure an Execution environment for the Demo Configure Job Templates for the Demo Configure Schedules for the jobs that need to repeat Note: This script has defaults that it overrides when run as part of make install that it derives from the environment (the repo that it is attached to and the branch that it is on). So if you need to re-run it, the most straightforward way to do this is to run make upgrade when using the make-based installation process.
+OpenShift GitOps (ArgoCD) OpenShift GitOps is central to this pattern as it is responsible for installing all of the other components. The installation process is driven through the installation of the clustergroup chart. This in turn reads the repo&rsquo;s global values file, which instructs it to read the hub values file. This is how the pattern knows to apply the Subscriptions and Applications listed further in the pattern.
+ODF (OpenShift Data Foundations) ODF is the storage framework that is needed to provide resilient storage for OpenShift Virtualization. It is managed via the helm chart here. This is basically the same chart that our Medical Diagnosis pattern uses (see here for details on the Medical Edge pattern&rsquo;s use of storage).
+Please note that this chart will create a Noobaa S3 bucket named nb.epoch_timestamp.cluster-domain which will not be destroyed when the cluster is destroyed.
+OpenShift Virtualization (KubeVirt) OpenShift Virtualization is a framework for running virtual machines as native Kubernetes resources. While it can run without hardware acceleration, the performance of virtual machines will suffer terribly; some testing on a similar workload indicated a 4-6x delay running without hardware acceleration, so at present this pattern requires hardware acceleration. The pattern provides a script deploy-kubevirt-worker.sh which will provision a metal worker to run virtual machines for the pattern.
+OpenShift Virtualization currently supports only AWS and on-prem clusters; this is because of the way that baremetal resources are provisioned in GCP and Azure. We hope that OpenShift Virtualization can support GCP and Azure soon.
+The installation of the OpenShift Virtualization HyperConverged deployment is controlled by the chart here.
+OpenShift Virtualization was chosen in this pattern to avoid dealing with the differences in galleries and templates of images between the different public cloud providers. The important thing from this pattern&rsquo;s standpoint is the availability of machine instances to manage (since we are simulating an Edge deployment scenario, which could either be bare metal instances or virtual machines); OpenShift Virtualization was the easiest and most portable way to spin up machine instances. It also provides mechanisms for defining the desired machine set declaratively.
+The creation of virtual machines is controlled by the chart here.
+More details about the way we use OpenShift Virtualization are available here.
+Ansible Automation Platform (AAP, formerly known as Ansible Tower) The use of Ansible Automation Platform is really the centerpiece of this pattern. We have recognized for some time that the notion and design principles of GitOps should apply to things outside of Kubernetes, and we believe this pattern gives us a way to do that.
+All of the Ansible interactions are defined in a Git Repository; the Ansible jobs that configure the VMs are designed to be idempotent (and are scheduled to run every 10 minutes on those VMs).
+The installation of AAP itself is governed by the chart here. The post-installation configuration of AAP is done via the ansible-load-controller.sh script.
+It is very much the intention of this pattern to make it easy to replace the specific Edge management use case with another one. Some ideas on how to do that can be found here.
+Specifics of the Ansible content for this pattern can be seen here.
+More details of the specifics of how AAP is configured are available here.
+Next Steps Help &amp; Feedback Report Bugs `,url:"https://validatedpatterns.io/patterns/ansible-edge-gitops/installation-details/",breadcrumb:"/patterns/ansible-edge-gitops/installation-details/"},"https://validatedpatterns.io/patterns/multicloud-gitops-amx/mcg-amx-managed-cluster/":{title:"Managed cluster sites",tags:[],content:` Attach a managed cluster (edge) to the management hub Understanding Red Hat Advanced Cluster Management requirements By default, Red Hat Advanced Cluster Management (RHACM) manages the clusterGroup applications that are deployed on all clusters. In the value-hub.yaml file, add a managedClusterCgroup for each cluster or group of clusters that you want to manage as one.
+managedClusterGroups: - name: region-one helmOverrides: - name: clusterGroup.isHubCluster value: false clusterSelector: matchLabels: clusterGroup: region-one The above YAML file segment deploys the clusterGroup applications on managed clusters with the label clusterGroup=region-one. Specific subscriptions and Operators, applications and projects for that clusterGroup are then managed in a value-region-one.yaml file. For example:
+namespaces: - config-demo projects: - config-demo applications: config-demo: name: config-demo namespace: config-demo project: config-demo path: charts/all/config-demo #Subscriptions can be added too - multicloud-gitops at present does not require subscriptions on its managed clusters #subscriptions: . # example-subscription # name: example-operator # namespace: example-namespace # channel: example-channel # csv: example-operator.v1.0.0 subscriptions: Ensure that you commit the changes and push them to GitHub so that GitOps can fetch your changes and apply them.
+Deploying a managed cluster by using Red Hat Advanced Cluster Management Prerequisites An OpenShift cluster
+To create an OpenShift cluster, go to the Red Hat Hybrid Cloud console.
+Select Services → Containers → Create cluster.
+Red Hat Advanced Cluster Management (RHACM) web console to join the managed cluster to the management hub
+After RHACM is installed, a message regarding a Web console update is available&#34; might be displayed. Follow the instructions and click the Refresh web console link.
+Procedure In the left navigation panel of web console, click local-cluster. Select All Clusters. The RHACM web console is displayed with Cluster* on the left navigation panel.
+On the Managed clusters tab, click Import cluster.
+On the Import an existing cluster page, enter the cluster name and choose KUBECONFIG as the &#34;import mode&#34;. Add the tag clusterGroup=region-one. Click Import.
+Now that RHACM is no longer deploying the managed cluster applications everywhere, you must indicate that the new cluster has the managed cluster role.
+Optional: Deploying a managed cluster by using cm-cli tool Prerequisites An OpenShift cluster
+To create an OpenShift cluster, go to the Red Hat Hybrid Cloud console.
+Select Services -&gt; Containers -&gt; Create cluster.
+The cm-cli tool
+Procedure Obtain the KUBECONFIG file from the managed cluster.
+Open a shell prompt and login into the management hub cluster by using either of the following methods:
+oc login or
+export KUBECONFIG=~/&lt;path_to_kubeconfig&gt; Run the following command:
+cm attach cluster --cluster &lt;cluster-name&gt; --cluster-kubeconfig &lt;path-to-path_to_kubeconfig&gt; Next steps Designate the new cluster as a managed cluster site
+Optional: Deploying a managed cluster by using the clusteradm tool Prerequisites An OpenShift cluster
+To create an OpenShift cluster, go to the Red Hat Hybrid Cloud console.
+Select Services → Containers → Create cluster.
+The clusteradm tool
+Procedure To deploy an edge cluster, you must to get the token from the management hub cluster. Run the following command on the existing management hub or datacenter cluster:
+clusteradm get token The command generates a token and shows you the command to use on the managed cluster.
+Login to the managed cluster with either of the following methods:
+oc login or
+export KUBECONFIG=~/&lt;path_to_kubeconfig&gt; To request that the managed join the hub cluster, run the following command:
+clusteradm join --hub-token &lt;token_from_clusteradm_get_token_command&gt; &lt;managed_cluster_name&gt; Accept the join request on the hub cluster:
+clusteradm accept --clusters &lt;managed_cluster_name&gt; Next steps Designate the new cluster as a managed cluster site
+Designate the new cluster as a managed cluster site If you use the command line tools such as clusteradm or cm-cli, you must explicitly indicate that the imported cluster is part of a specific clusterGroup. Some examples of clusterGroup are factory, devel, or prod.
+To tag the cluster as clusterGroup=&lt;managed-cluster-group&gt;, complete the following steps.
+Procedure To find the new cluster, run the following command:
+oc get managedcluster.cluster.open-cluster-management.io To apply the label, run the following command:
+oc label managedcluster.cluster.open-cluster-management.io/YOURCLUSTER site=managed-cluster Verification Go to your managed cluster (edge) OpenShift console and check for the open-cluster-management-agent pod being launched. It might take a while for the RHACM agent and agent-addons to launch. After that, the OpenShift GitOps Operator is installed. On successful installation, launch the OpenShift GitOps (ArgoCD) console from the top right of the OpenShift console.
+`,url:"https://validatedpatterns.io/patterns/multicloud-gitops-amx/mcg-amx-managed-cluster/",breadcrumb:"/patterns/multicloud-gitops-amx/mcg-amx-managed-cluster/"},"https://validatedpatterns.io/patterns/multicloud-gitops-portworx/managed-cluster/":{title:"Managed cluster sites",tags:[],content:`Attach a managed cluster (edge) to the management hub Understanding Red Hat Advanced Cluster Management requirements Allow Red Hat Advanced Cluster Management (RHACM) to deploy the managed cluster application to a subset of clusters.
+By default the clusterGroup applications are deployed on all clusters that RHACM manages. In the value-hub.yaml, file add a managedClusterCgroup for each cluster or group of clusters that you want to manage as one.
+managedClusterGroups: - name: region-one helmOverrides: - name: clusterGroup.isHubCluster value: false clusterSelector: matchLabels: clusterGroup: region-one The above YAML file segment deploys the clusterGroup applications on managed clusters with the label clusterGroup=region-one. Specific subscriptions and Operators, applications and projects for that clusterGroup are then managed in a value-region-one.yaml file. For example:
+namespaces: - config-demo projects: - config-demo applications: config-demo: name: config-demo namespace: config-demo project: config-demo path: charts/all/config-demo #Subscriptions can be added too - multicloud-gitops at present does not require subscriptions on its managed clusters #subscriptions: # example-subscription: # name: example-operator # namespace: example-namespace # channel: example-channel # csv: example-operator.v1.0.0 subscriptions: Important: Ensure that you commit the changes and push them to GitHub so that GitOps can fetch your changes and apply them.
+Deploying a managed cluster Prerequisites An OpenShift cluster To create an OpenShift cluster, go to the Red Hat Hybrid Cloud console. Select Services -&gt; Containers -&gt; Create cluster. To join the managed cluster to the management hub, you can:
+Use the Red Hat Advanced Cluster Management (RHACM) web console Use the cm tool Use the clusteradm tool Using Red Hat Advanced Cluster Management web console to set up managed cluster After RHACM is installed, a message regarding a &ldquo;Web console update is available&rdquo; might be displayed. Click the &ldquo;Refresh web console&rdquo; link.
+In the left navigation panel of web console, click local-cluster. Select All Clusters. The RHACM web console is displayed with Cluster* on the left navigation panel.
+On the Managed clusters tab, click Import cluster.
+On the Import an existing cluster page, enter the cluster name and choose Kubeconfig as the &ldquo;import mode&rdquo;. Add the tag clusterGroup=region-one. Click Import. You can now skip to the section Managed cluster is joined but ignore the part about adding the site tag.
+Using the cm tool to set up a managed cluster Install the cm (cluster management) command-line tool. See details here
+Obtain the KUBECONFIG file from the managed-cluster cluster.
+On the command-line login into the management hub cluster (use oc login or export the KUBECONFIG).
+Run the following command:
+cm attach cluster --cluster &lt;cluster-name&gt; --cluster-kubeconfig &lt;path-to-KUBECONFIG&gt; Skip to the section Managed cluster is joined
+Using the clusteradm tool to set up a managed cluster You can also use clusteradm to join a cluster. The following instructions explain what needs to be done. clusteradm is still in testing.
+To deploy a edge cluster you will need to get the management hub cluster&rsquo;s token. You will need to install clusteradm. On the existing management hub cluster:
+clusteradm get token
+When you run the clusteradm command above it replies with the token and also shows you the command to use on the managed cluster. So first you must login to the managed cluster
+oc login or
+export KUBECONFIG=~/my-ocp-env/managed-cluster
+Then request to that the managed cluster join the management hub
+clusteradm join --hub-token &lt;token from clusteradm get token command &gt; &lt;managed cluster name&gt;
+Back on the hub cluster accept the join request
+clusteradm accept --clusters &lt;managed-cluster-name&gt;
+Skip to the section Managed cluster is joined
+Managed cluster is joined Designate the new cluster as a managed cluster site Now that ACM is no longer deploying the managed cluster applications everywhere, we need to explicitly indicate that the new cluster has the managed cluster role. If you haven&rsquo;t tagged the cluster as clusterGroup=region-one then we can that here.
+We do this by adding the label referenced in the managedSite&rsquo;s clusterSelector.
+Find the new cluster
+oc get managedcluster.cluster.open-cluster-management.io
+Apply the label
+oc label managedcluster.cluster.open-cluster-management.io/YOURCLUSTER site=managed-cluster
+Verification Go to your managed cluster (edge) OpenShift console and check for the open-cluster-management-agent pod being launched. Be patient, it will take a while for the RHACM agent and agent-addons to launch. After that, the OpenShift GitOps Operator is installed. On successful installation, launch the OpenShift GitOps (ArgoCD) console from the top right of the OpenShift console.
+`,url:"https://validatedpatterns.io/patterns/multicloud-gitops-portworx/managed-cluster/",breadcrumb:"/patterns/multicloud-gitops-portworx/managed-cluster/"},"https://validatedpatterns.io/patterns/multicloud-gitops-qat/mcg-qat-managed-cluster/":{title:"Managed cluster sites",tags:[],content:` Attach a managed cluster (edge) to the management hub Understanding Red Hat Advanced Cluster Management requirements By default, Red Hat Advanced Cluster Management (RHACM) manages the clusterGroup applications that are deployed on all clusters. In the value-hub.yaml file, add a managedClusterCgroup for each cluster or group of clusters that you want to manage as one.
+managedClusterGroups: - name: region-one helmOverrides: - name: clusterGroup.isHubCluster value: false clusterSelector: matchLabels: clusterGroup: region-one The above YAML file segment deploys the clusterGroup applications on managed clusters with the label clusterGroup=region-one. Specific subscriptions and Operators, applications and projects for that clusterGroup are then managed in a value-region-one.yaml file. For example:
+namespaces: - config-demo projects: - config-demo applications: config-demo: name: config-demo namespace: config-demo project: config-demo path: charts/all/config-demo #Subscriptions can be added too - multicloud-gitops at present does not require subscriptions on its managed clusters #subscriptions: . # example-subscription # name: example-operator # namespace: example-namespace # channel: example-channel # csv: example-operator.v1.0.0 subscriptions: Ensure that you commit the changes and push them to GitHub so that GitOps can fetch your changes and apply them.
+Deploying a managed cluster by using Red Hat Advanced Cluster Management Prerequisites An OpenShift cluster
+To create an OpenShift cluster, go to the Red Hat Hybrid Cloud console.
+Select Services → Containers → Create cluster.
+Red Hat Advanced Cluster Management (RHACM) web console to join the managed cluster to the management hub
+After RHACM is installed, a message regarding a Web console update is available&#34; might be displayed. Follow the instructions and click the Refresh web console link.
+Procedure In the left navigation panel of web console, click local-cluster. Select All Clusters. The RHACM web console is displayed with Cluster* on the left navigation panel.
+On the Managed clusters tab, click Import cluster.
+On the Import an existing cluster page, enter the cluster name and choose KUBECONFIG as the &#34;import mode&#34;. Add the tag clusterGroup=region-one. Click Import.
+Now that RHACM is no longer deploying the managed cluster applications everywhere, you must indicate that the new cluster has the managed cluster role.
+Optional: Deploying a managed cluster by using cm-cli tool Prerequisites An OpenShift cluster
+To create an OpenShift cluster, go to the Red Hat Hybrid Cloud console.
+Select Services -&gt; Containers -&gt; Create cluster.
+The cm-cli tool
+Procedure Obtain the KUBECONFIG file from the managed cluster.
+Open a shell prompt and login into the management hub cluster by using either of the following methods:
+oc login or
+export KUBECONFIG=~/&lt;path_to_kubeconfig&gt; Run the following command:
+cm attach cluster --cluster &lt;cluster-name&gt; --cluster-kubeconfig &lt;path-to-path_to_kubeconfig&gt; Next steps Designate the new cluster as a managed cluster site
+Optional: Deploying a managed cluster by using the clusteradm tool Prerequisites An OpenShift cluster
+To create an OpenShift cluster, go to the Red Hat Hybrid Cloud console.
+Select Services → Containers → Create cluster.
+The clusteradm tool
+Procedure To deploy an edge cluster, you must to get the token from the management hub cluster. Run the following command on the existing management hub or datacenter cluster:
+clusteradm get token The command generates a token and shows you the command to use on the managed cluster.
+Login to the managed cluster with either of the following methods:
+oc login or
+export KUBECONFIG=~/&lt;path_to_kubeconfig&gt; To request that the managed join the hub cluster, run the following command:
+clusteradm join --hub-token &lt;token_from_clusteradm_get_token_command&gt; &lt;managed_cluster_name&gt; Accept the join request on the hub cluster:
+clusteradm accept --clusters &lt;managed_cluster_name&gt; Next steps Designate the new cluster as a managed cluster site
+Designate the new cluster as a managed cluster site If you use the command line tools such as clusteradm or cm-cli, you must explicitly indicate that the imported cluster is part of a specific clusterGroup. Some examples of clusterGroup are factory, devel, or prod.
+To tag the cluster as clusterGroup=&lt;managed-cluster-group&gt;, complete the following steps.
+Procedure To find the new cluster, run the following command:
+oc get managedcluster.cluster.open-cluster-management.io To apply the label, run the following command:
+oc label managedcluster.cluster.open-cluster-management.io/YOURCLUSTER site=managed-cluster Verification Go to your managed cluster (edge) OpenShift console and check for the open-cluster-management-agent pod being launched. It might take a while for the RHACM agent and agent-addons to launch. After that, the OpenShift GitOps Operator is installed. On successful installation, launch the OpenShift GitOps (ArgoCD) console from the top right of the OpenShift console.
+`,url:"https://validatedpatterns.io/patterns/multicloud-gitops-qat/mcg-qat-managed-cluster/",breadcrumb:"/patterns/multicloud-gitops-qat/mcg-qat-managed-cluster/"},"https://validatedpatterns.io/patterns/multicloud-gitops-sgx-hello-world/mcg-sgx-hello-world-managed-cluster/":{title:"Managed cluster sites",tags:[],content:` Attach a managed cluster (edge) to the management hub Understanding Red Hat Advanced Cluster Management requirements By default, Red Hat Advanced Cluster Management (RHACM) manages the clusterGroup applications that are deployed on all clusters. In the value-hub.yaml file, add a managedClusterCgroup for each cluster or group of clusters that you want to manage as one.
+managedClusterGroups: - name: region-one helmOverrides: - name: clusterGroup.isHubCluster value: false clusterSelector: matchLabels: clusterGroup: region-one The above YAML file segment deploys the clusterGroup applications on managed clusters with the label clusterGroup=region-one. Specific subscriptions and Operators, applications and projects for that clusterGroup are then managed in a value-region-one.yaml file. For example:
+namespaces: - config-demo projects: - config-demo applications: config-demo: name: config-demo namespace: config-demo project: config-demo path: charts/all/config-demo #Subscriptions can be added too - multicloud-gitops at present does not require subscriptions on its managed clusters #subscriptions: . # example-subscription # name: example-operator # namespace: example-namespace # channel: example-channel # csv: example-operator.v1.0.0 subscriptions: Ensure that you commit the changes and push them to GitHub so that GitOps can fetch your changes and apply them.
+Deploying a managed cluster by using Red Hat Advanced Cluster Management Prerequisites An OpenShift cluster
+To create an OpenShift cluster, go to the Red Hat Hybrid Cloud console.
+Select Services → Containers → Create cluster.
+Red Hat Advanced Cluster Management (RHACM) web console to join the managed cluster to the management hub
+After RHACM is installed, a message regarding a Web console update is available&#34; might be displayed. Follow the instructions and click the Refresh web console link.
+Procedure In the left navigation panel of web console, click local-cluster. Select All Clusters. The RHACM web console is displayed with Cluster* on the left navigation panel.
+On the Managed clusters tab, click Import cluster.
+On the Import an existing cluster page, enter the cluster name and choose KUBECONFIG as the &#34;import mode&#34;. Add the tag clusterGroup=region-one. Click Import.
+Now that RHACM is no longer deploying the managed cluster applications everywhere, you must indicate that the new cluster has the managed cluster role.
+Optional: Deploying a managed cluster by using cm-cli tool Prerequisites An OpenShift cluster
+To create an OpenShift cluster, go to the Red Hat Hybrid Cloud console.
+Select Services -&gt; Containers -&gt; Create cluster.
+The cm-cli tool
+Procedure Obtain the KUBECONFIG file from the managed cluster.
+Open a shell prompt and login into the management hub cluster by using either of the following methods:
+oc login or
+export KUBECONFIG=~/&lt;path_to_kubeconfig&gt; Run the following command:
+cm attach cluster --cluster &lt;cluster-name&gt; --cluster-kubeconfig &lt;path-to-path_to_kubeconfig&gt; Next steps Designate the new cluster as a managed cluster site
+Optional: Deploying a managed cluster by using the clusteradm tool Prerequisites An OpenShift cluster
+To create an OpenShift cluster, go to the Red Hat Hybrid Cloud console.
+Select Services → Containers → Create cluster.
+The clusteradm tool
+Procedure To deploy an edge cluster, you must to get the token from the management hub cluster. Run the following command on the existing management hub or datacenter cluster:
+clusteradm get token The command generates a token and shows you the command to use on the managed cluster.
+Login to the managed cluster with either of the following methods:
+oc login or
+export KUBECONFIG=~/&lt;path_to_kubeconfig&gt; To request that the managed join the hub cluster, run the following command:
+clusteradm join --hub-token &lt;token_from_clusteradm_get_token_command&gt; &lt;managed_cluster_name&gt; Accept the join request on the hub cluster:
+clusteradm accept --clusters &lt;managed_cluster_name&gt; Next steps Designate the new cluster as a managed cluster site
+Designate the new cluster as a managed cluster site If you use the command line tools such as clusteradm or cm-cli, you must explicitly indicate that the imported cluster is part of a specific clusterGroup. Some examples of clusterGroup are factory, devel, or prod.
+To tag the cluster as clusterGroup=&lt;managed-cluster-group&gt;, complete the following steps.
+Procedure To find the new cluster, run the following command:
+oc get managedcluster.cluster.open-cluster-management.io To apply the label, run the following command:
+oc label managedcluster.cluster.open-cluster-management.io/YOURCLUSTER site=managed-cluster Verification Go to your managed cluster (edge) OpenShift console and check for the open-cluster-management-agent pod being launched. It might take a while for the RHACM agent and agent-addons to launch. After that, the OpenShift GitOps Operator is installed. On successful installation, launch the OpenShift GitOps (ArgoCD) console from the top right of the OpenShift console.
+`,url:"https://validatedpatterns.io/patterns/multicloud-gitops-sgx-hello-world/mcg-sgx-hello-world-managed-cluster/",breadcrumb:"/patterns/multicloud-gitops-sgx-hello-world/mcg-sgx-hello-world-managed-cluster/"},"https://validatedpatterns.io/patterns/multicloud-gitops-sgx/mcg-sgx-managed-cluster/":{title:"Managed cluster sites",tags:[],content:` Attach a managed cluster (edge) to the management hub Understanding Red Hat Advanced Cluster Management requirements By default, Red Hat Advanced Cluster Management (RHACM) manages the clusterGroup applications that are deployed on all clusters. In the value-hub.yaml file, add a managedClusterCgroup for each cluster or group of clusters that you want to manage as one.
+managedClusterGroups: - name: region-one helmOverrides: - name: clusterGroup.isHubCluster value: false clusterSelector: matchLabels: clusterGroup: region-one The above YAML file segment deploys the clusterGroup applications on managed clusters with the label clusterGroup=region-one. Specific subscriptions and Operators, applications and projects for that clusterGroup are then managed in a value-region-one.yaml file. For example:
+namespaces: - config-demo projects: - config-demo applications: config-demo: name: config-demo namespace: config-demo project: config-demo path: charts/all/config-demo #Subscriptions can be added too - multicloud-gitops at present does not require subscriptions on its managed clusters #subscriptions: . # example-subscription # name: example-operator # namespace: example-namespace # channel: example-channel # csv: example-operator.v1.0.0 subscriptions: Ensure that you commit the changes and push them to GitHub so that GitOps can fetch your changes and apply them.
+Deploying a managed cluster by using Red Hat Advanced Cluster Management Prerequisites An OpenShift cluster
+To create an OpenShift cluster, go to the Red Hat Hybrid Cloud console.
+Select Services → Containers → Create cluster.
+Red Hat Advanced Cluster Management (RHACM) web console to join the managed cluster to the management hub
+After RHACM is installed, a message regarding a Web console update is available&#34; might be displayed. Follow the instructions and click the Refresh web console link.
+Procedure In the left navigation panel of web console, click local-cluster. Select All Clusters. The RHACM web console is displayed with Cluster* on the left navigation panel.
+On the Managed clusters tab, click Import cluster.
+On the Import an existing cluster page, enter the cluster name and choose KUBECONFIG as the &#34;import mode&#34;. Add the tag clusterGroup=region-one. Click Import.
+Now that RHACM is no longer deploying the managed cluster applications everywhere, you must indicate that the new cluster has the managed cluster role.
+Optional: Deploying a managed cluster by using cm-cli tool Prerequisites An OpenShift cluster
+To create an OpenShift cluster, go to the Red Hat Hybrid Cloud console.
+Select Services -&gt; Containers -&gt; Create cluster.
+The cm-cli tool
+Procedure Obtain the KUBECONFIG file from the managed cluster.
+Open a shell prompt and login into the management hub cluster by using either of the following methods:
+oc login or
+export KUBECONFIG=~/&lt;path_to_kubeconfig&gt; Run the following command:
+cm attach cluster --cluster &lt;cluster-name&gt; --cluster-kubeconfig &lt;path-to-path_to_kubeconfig&gt; Next steps Designate the new cluster as a managed cluster site
+Optional: Deploying a managed cluster by using the clusteradm tool Prerequisites An OpenShift cluster
+To create an OpenShift cluster, go to the Red Hat Hybrid Cloud console.
+Select Services → Containers → Create cluster.
+The clusteradm tool
+Procedure To deploy an edge cluster, you must to get the token from the management hub cluster. Run the following command on the existing management hub or datacenter cluster:
+clusteradm get token The command generates a token and shows you the command to use on the managed cluster.
+Login to the managed cluster with either of the following methods:
+oc login or
+export KUBECONFIG=~/&lt;path_to_kubeconfig&gt; To request that the managed join the hub cluster, run the following command:
+clusteradm join --hub-token &lt;token_from_clusteradm_get_token_command&gt; &lt;managed_cluster_name&gt; Accept the join request on the hub cluster:
+clusteradm accept --clusters &lt;managed_cluster_name&gt; Next steps Designate the new cluster as a managed cluster site
+Designate the new cluster as a managed cluster site If you use the command line tools such as clusteradm or cm-cli, you must explicitly indicate that the imported cluster is part of a specific clusterGroup. Some examples of clusterGroup are factory, devel, or prod.
+To tag the cluster as clusterGroup=&lt;managed-cluster-group&gt;, complete the following steps.
+Procedure To find the new cluster, run the following command:
+oc get managedcluster.cluster.open-cluster-management.io To apply the label, run the following command:
+oc label managedcluster.cluster.open-cluster-management.io/YOURCLUSTER site=managed-cluster Verification Go to your managed cluster (edge) OpenShift console and check for the open-cluster-management-agent pod being launched. It might take a while for the RHACM agent and agent-addons to launch. After that, the OpenShift GitOps Operator is installed. On successful installation, launch the OpenShift GitOps (ArgoCD) console from the top right of the OpenShift console.
+`,url:"https://validatedpatterns.io/patterns/multicloud-gitops-sgx/mcg-sgx-managed-cluster/",breadcrumb:"/patterns/multicloud-gitops-sgx/mcg-sgx-managed-cluster/"},"https://validatedpatterns.io/patterns/multicloud-gitops/mcg-managed-cluster/":{title:"Managed cluster sites",tags:[],content:`Attach a managed cluster (edge) to the management hub Understanding Red Hat Advanced Cluster Management requirements By default, Red Hat Advanced Cluster Management (RHACM) manages the clusterGroup applications that are deployed on all clusters. In the value-hub.yaml file, add a managedClusterCgroup for each cluster or group of clusters that you want to manage as one.
+managedClusterGroups: - name: region-one helmOverrides: - name: clusterGroup.isHubCluster value: false clusterSelector: matchLabels: clusterGroup: region-one The above YAML file segment deploys the clusterGroup applications on managed clusters with the label clusterGroup=region-one. Specific subscriptions and Operators, applications and projects for that clusterGroup are then managed in a value-region-one.yaml file. For example:
+namespaces: - config-demo projects: - config-demo applications: config-demo: name: config-demo namespace: config-demo project: config-demo path: charts/all/config-demo #Subscriptions can be added too - multicloud-gitops at present does not require subscriptions on its managed clusters #subscriptions: . # example-subscription # name: example-operator # namespace: example-namespace # channel: example-channel # csv: example-operator.v1.0.0 subscriptions: Ensure that you commit the changes and push them to GitHub so that GitOps can fetch your changes and apply them.
+Deploying a managed cluster by using Red Hat Advanced Cluster Management Prerequistes An OpenShift cluster
+To create an OpenShift cluster, go to the Red Hat Hybrid Cloud console.
+Select Services → Containers → Create cluster.
+Red Hat Advanced Cluster Management (RHACM) web console to join the managed cluster to the management hub
+After RHACM is installed, a message regarding a Web console update is available&#34; might be displayed. Follow the instructions and click the Refresh web console link.
+Procedure In the left navigation panel of web console, click local-cluster. Select All Clusters. The RHACM web console is displayed with Cluster* on the left navigation panel.
+On the Managed clusters tab, click Import cluster.
+On the Import an existing cluster page, enter the cluster name and choose KUBECONFIG as the &#34;import mode&#34;. Add the tag clusterGroup=region-one. Click Import.
+Now that RHACM is no longer deploying the managed cluster applications everywhere, you must indicate that the new cluster has the managed cluster role.
+Optional: Deploying a managed cluster by using cm-cli tool Prerequistes An OpenShift cluster
+To create an OpenShift cluster, go to the Red Hat Hybrid Cloud console.
+Select Services -&gt; Containers -&gt; Create cluster.
+The cm-cli tool
+Procedure Obtain the KUBECONFIG file from the managed cluster.
+Open a shell prompt and login into the management hub cluster by using either of the following methods:
+oc login or
+export KUBECONFIG=~/&lt;path_to_kubeconfig&gt; Run the following command:
+cm attach cluster --cluster &lt;cluster-name&gt; --cluster-kubeconfig &lt;path-to-path_to_kubeconfig&gt; Next steps Designate the new cluster as a managed cluster site
+Optional: Deploying a managed cluster by using the clusteradm tool Prerequistes An OpenShift cluster
+To create an OpenShift cluster, go to the Red Hat Hybrid Cloud console.
+Select Services → Containers → Create cluster.
+The clusteradm tool
+Procedure To deploy an edge cluster, you must to get the token from the management hub cluster. Run the following command on the existing management hub or datacenter cluster:
+clusteradm get token The command generates a token and shows you the command to use on the managed cluster.
+Login to the managed cluster with either of the following methods:
+oc login or
+export KUBECONFIG=~/&lt;path_to_kubeconfig&gt; To request that the managed join the hub cluster, run the following command:
+clusteradm join --hub-token &lt;token_from_clusteradm_get_token_command&gt; &lt;managed_cluster_name&gt; Accept the join request on the hub cluster:
+clusteradm accept --clusters &lt;managed_cluster_name&gt; Next steps Designate the new cluster as a managed cluster site
+Designate the new cluster as a managed cluster site If you use the command line tools such as clusteradm or cm-cli, you must explicitly indicate that the imported cluster is part of a specific clusterGroup. Some examples of clusterGroup are factory, devel, or prod.
+To tag the cluster as clusterGroup=&lt;managed-cluster-group&gt;, complete the following steps.
+Procedure To find the new cluster, run the following command:
+oc get managedcluster.cluster.open-cluster-management.io To apply the label, run the following command:
+oc label managedcluster.cluster.open-cluster-management.io/YOURCLUSTER site=managed-cluster Verification Go to your managed cluster (edge) OpenShift console and check for the open-cluster-management-agent pod being launched. It might take a while for the RHACM agent and agent-addons to launch. After that, the OpenShift GitOps Operator is installed. On successful installation, launch the OpenShift GitOps (ArgoCD) console from the top right of the OpenShift console.
+`,url:"https://validatedpatterns.io/patterns/multicloud-gitops/mcg-managed-cluster/",breadcrumb:"/patterns/multicloud-gitops/mcg-managed-cluster/"},"https://validatedpatterns.io/patterns/devsecops/devel-cluster/":{title:"Secured Development Cluster",tags:[],content:`Having a development cluster (devel) join the hub Introduction Development clusters are responsible for building applications and delivering the applications to a secured registry. The development cluster defines a secure pipeline that includes code and image scans and image signing before delivering them to the registry. OpenShift Pipelines is used for the continuous integration (CI). The Quay registry is deployed on the hub and therefore integration is required for the development pipeline to push images to the registry.
+Development clusters also need to be secured and so one part of the deployment is Advanced Cluster Security with a secured configuration. This allows ACS to monitor and report on security issues on the cluster. ACS secured sites report to an ACS Central application that is deployed on the hub.
+Allow ACM to deploy the devel applications to a subset of clusters By default the devel applications are deployed on any development clusters that ACM knows about.
+managedClusterGroups: - name: devel helmOverrides: - name: clusterGroup.isHubCluster value: &#34;false&#34; clusterSelector: matchLabels: clusterGroup: devel matchExpressions: - key: vendor operator: In values: - OpenShift Remember to commit the changes and push to GitHub so that GitOps can see your changes and apply them.
+Deploy a development (devel) cluster For instructions on how to prepare and import a development (devel) cluster please read the section importing a cluster. Use clusterGroup=devel. .
+You are done importing the development cluster That&rsquo;s it! Go to your devel (edge) OpenShift console and check for the open-cluster-management-agent pod being launched. Be patient, it will take a while for the ACM agent and agent-addons to launch. After that, the operator OpenShift GitOps will run. When it&rsquo;s finished check that all applications have synced in OpenShift GitOps. Select &ldquo;Devel Argo CD&rdquo; from the OpenShift Applications menu.
+Then look at the GitOps applications and make sure they have synced completely.
+Confirming successful deployment There are a number of steps you can do to check that the components have deployed:
+Pipelines should be available in the console on the left hand side.
+Run a pipeline and check the build and if the image gets updated in the Quay registry on the Hub.
+You should be able to select the route to the demo application in the test environment.
+The development cluster name should show up in the ACS Central console.
+Next up Deploy the the Multicluster DevSecOps secured production cluster
+`,url:"https://validatedpatterns.io/patterns/devsecops/devel-cluster/",breadcrumb:"/patterns/devsecops/devel-cluster/"},"https://validatedpatterns.io/patterns/retail/store/":{title:"Store Sites",tags:[],content:`Having a store (edge) cluster join the datacenter (hub) Allow ACM to deploy the store application to a subset of clusters A store (&ldquo;ATLANTA&rdquo;) is installed on the hub cluster by default. This feature is interesting if you want to see how ACM can manage a remote cluster to install the same application on a different cluster.
+The way we apply this is through the managedClusterGroups block in values-hub.yaml:
+managedClusterGroups: - name: store clusterSelector: matchLabels: clusterGroup: raleigh matchExpressions: - key: vendor operator: In values: - OpenShift Any cluster joined with the label clusterGroup=raleigh will be assigned the policies that deploy the store app to them.
+Deploy a store cluster Rather than provide instructions on creating a store cluster it is assumed that an OpenShift cluster has already been created. Use the openshift-install program provided at cloud.redhat.com
+There are a three ways to join the store to the datacenter.
+Using the ACM user interface Using the cm tool Using the clusteradm tool Store setup using the ACM UI After ACM is installed a message regarding a &ldquo;Web console update is available&rdquo; may be displayed. Click on the &ldquo;Refresh web console&rdquo; link.
+On the upper-left side you&rsquo;ll see a pull down labeled &ldquo;local-cluster&rdquo;. Select &ldquo;All Clusters&rdquo; from this pull down. This will navigate to the ACM console and to its &ldquo;Clusters&rdquo; section
+Select the &ldquo;Import cluster&rdquo; option beside the Create Cluster button.
+On the &ldquo;Import an existing cluster&rdquo; page, enter the cluster name and choose Kubeconfig as the &ldquo;import mode&rdquo;. Add the tag site=store Press import. Done.
+Using this method, you are done. Skip to the section Store is joined but ignore the part about adding the site tag.
+Store setup using cm tool Install the cm (cluster management) command-line tool. See details here
+Obtain the KUBECONFIG file from the edge/store cluster.
+On the command-line login into the hub/datacenter cluster (use oc login or export the KUBECONFIG).
+Run the following command:
+cm attach cluster --cluster &lt;cluster-name&gt; --cluster-kubeconfig &lt;path-to-KUBECONFIG&gt; Skip to the section Store is joined
+Store setup using clusteradm tool You can also use clusteradm to join a cluster. The following instructions explain what needs to be done. clusteradm is still in testing.
+To deploy a edge cluster you will need to get the datacenter (or hub) cluster&rsquo;s token. You will need to install clusteradm. On the existing datacenter cluster:
+clusteradm get token
+When you run the clusteradm command above it replies with the token and also shows you the command to use on the store. So first you must login to the store cluster
+oc login or
+export KUBECONFIG=~/my-ocp-env/store
+Then request to that the store join the datacenter hub
+clusteradm join --hub-token &lt;token from clusteradm get token command &gt; &lt;store cluster name&gt;
+Back on the hub cluster accept the join request
+clusteradm accept --clusters &lt;store-cluster-name&gt;
+Skip to the next section, Store is joined
+Store is joined You&rsquo;re done That&rsquo;s it! Go to your store (edge) OpenShift console and check for the open-cluster-management-agent pod being launched. Be patient, it will take a while for the ACM agent and agent-addons to launch. After that, the operator OpenShift GitOps will run. When it&rsquo;s finished coming up launch the OpenShift GitOps (ArgoCD) console from the top right of the OpenShift console.
+`,url:"https://validatedpatterns.io/patterns/retail/store/",breadcrumb:"/patterns/retail/store/"},"https://validatedpatterns.io/learn/validated_patterns_frameworks/":{title:"Validated patterns frameworks",tags:[],content:` Introduction Validated patterns provides two frameworks to deploy applications: the OpenShift-based Validated Patterns framework and the Ansible GitOps Framework (AGOF).
+The OpenShift-based validated patterns framework is the most common method for deploying applications and infrastructure on the OpenShift Container Platform. It offers a set of predefined configurations and patterns that follow best practices and are validated by Red Hat.
+Ansible GitOps Framework (AGOF) is an alternative framework, designed to provide a framework for GitOps without Kubernetes. AGOF is not a pattern itself; it is a framework for installing Ansible Automation Platform (AAP), and then using that as the GitOps engine to drive other pattern work. AGOF comes with code to install VMs in AWS, if desired, or else it can work with previously provisioned VMs, or a functional AAP Controller endpoint.
+The goal with either framework, is that developers, operators, security, and architects build a secure and repeatable day one deployment mechanism and maintenance automation for day two operations.
+`,url:"https://validatedpatterns.io/learn/validated_patterns_frameworks/",breadcrumb:"/learn/validated_patterns_frameworks/"},"https://validatedpatterns.io/learn/vp_openshift_framework/":{title:"Validated pattern structure",tags:[],content:` OpenShift framework fundamentals The OpenShift validated patterns framework uses OpenShift GitOps (ArgoCD) as the primary driver for deploying patterns and keeping them up to date. Validated patterns use Helm charts as the primary artifacts for GitOps. Helm charts provide a mechanism for templating that is powerful when building repeatable, automated deployments across different deployment environments (i.e. clouds, data-centers, edge, etc.)
+The framework provides consistency across any cloud provider - public or private. So while you could automate the handling for each of the cloud providers, the framework utilizes one Kubernetes distribution that runs on public or private clouds - the hybrid and/or multi cloud model.
+Many Cloud Native Computing Foundation (CNCF) projects use Operators to manage the lifecycle of their service. Whenever possible, validated patterns will make use of these Operators to deploy the application service.
+Red Hat Advanced Cluster Management (ACM) is primarily used to automate the deployment of edge clusters. It provides subscription information for specific deployment sites.
+OpenShift Pipelines is used to automate builds and keep image repositories up to date.
+Pattern directories tour Examining any of the existing patterns reveals the important organizational part of the validated patterns framework. Let’s take a look at a couple of the existing validated patterns: Multicluster GitOps and Industrial Edge.
+Multicloud GitOps The Multicloud GitOps approach enables centralized management of multiple cloud deployments across both public and private clouds, including workloads and the secure handling of secrets across environments. This approach is built on patterns that consist of two key components: a &#34;common&#34; element, which serves as a foundational framework shared by nearly all patterns, and a pattern-specific element that builds on the common framework with tailored content. This section focuses on the standardized directory structure used in Multicloud GitOps repositories for validated patterns in multicloud setups. By following the well-structured directory layout illustrated here, teams can streamline deployment processes across clouds, reduce configuration drift, enhance automation, and maintain a single source of truth for both infrastructure and application code.
+~/g/multicloud-gitops on main ◦ tree -L 2 . ├── ansible ├── ansible.cfg ├── charts │ └── all │ └── region ├── common │ ├── acm | ├── ansible | ├── Changes.md │ ├── clustergroup │ ├── common -&gt; . │ ├── examples │ ├── golang-external-secrets │ ├── hashicorp-vault │ ├── letsencrypt | ├── LICENSE | ├── Makefile | ├── operator-install | ├── README.md │ ├── reference-output.yaml │ ├── scripts │ ├── tests │ └── values-global.yaml ├── LICENSE ├── Makefile ├── overrides │ ├── values-AWS.yaml │ └── values-IBMCloud.yaml ├── pattern.sh -&gt; ./common/scripts/pattern-util.sh ├── README.md ├── tests ├── values-global.yaml ├── values-global-one.yaml ├── values-hub.yaml ├── values-secret-multicloud-gitops.yaml └── values-secret.yaml.template 20 directories, 77 files First we notice some subdirectories: charts and common, along with values- yaml files.
+Industrial edge ~/g/industrial-edge on stable-2.0 ◦ tree -L 2 . ├── ansible ├── ansible.cfg ├── Changes.md ├── charts │ ├── datacenter │ └─ factory | └── secrets ├── common │ ├── acm | ├── ansible | ├── Changes.md │ ├── clustergroup │ ├── common -&gt; . │ ├── examples │ ├── golang-external-secrets │ ├── hashicorp-vault │ ├── letsencrypt | ├── LICENSE | ├── Makefile | ├── operator-install │ ├── scripts │ ├── tests │ └── values-global.yaml ├── docs │ ├── images │ └── old-deployment-map.txt ├── images │ ├── import-cluster.png │ ├── import-with-kubeconfig.png │ └── launch-acm-console.png ├── LICENSE ├── Makefile ├── overrides | ├── values-prod-imagedata.yaml │ └── values-test-imagedata.yaml ├── README.md |── pattern.sh -&gt; ./common/scripts/pattern-util.sh ├── scripts │ ├── secret.sh │ └── sleep-seed.sh ├── SUPPORT_AGREEMENT.md ├── tests ├── values-datacenter.yaml ├── values-factory.yaml ├── values-global.yaml ├── values-hub.yaml -&gt; values-datacenter.yaml └── values-secret.yaml.template 25 directories, 98 files We see the same or similar files in the both patterns directories.
+The common directory The core components that make the Validated Patterns framework are contained in the common repository. These include:
+OpenShift GitOps configuration
+Supports our clusterGroup and GitOps policies
+Validated Pattern framework build scripts and Makefiles
+Secrets Management with HashiCorp Vault
+Operator CRDs and other assets
+Various utility scripts
+The common repository contains all the shared manifests for the Validated Patterns Framework. These components are configured to work together within the GitOps framework. Instead of duplicating configurations across patterns, shared technologies are centralized in this common directory. Pattern-specific post-deployment configurations, if needed, should be added to the Helm charts in the charts directory. Typically, you won’t need to modify the common directory unless working on the framework itself.
+Breakdown of common repository This table details the key components of the common repository:
+Component Description acm
+Contains the helm charts which contains policies and is used to configure the deployment of the Advance Cluster Manager.
+ansible
+This directory contains the ansible roles and modules that support the secrets management for a pattern.
+clustergroup
+Contains the helm chart used to create namespace, subscriptions, projects, and applications described in the values files. This is the seed for all patterns.
+golang-external-secrets
+Helm chart for External Secrets Operator that integrates external secret management systems like AWS Secrets Manager, HashiCorp Vault, Google Secrets Manager, Azure Key Vault, IBM Cloud Secrets Manager, Akeyless.
+hashicorp-vault
+Contains the helm chart for HashiCorp Vault.
+operator-install
+Contains the helm chart used by the Validated Patterns Operator to create the openshift-gitops component and create the initial ArgoCD applications for the Validated Pattern.
+scripts
+Directory which contains utility scripts used by the Validated Pattern Framework.
+The charts directory This is where validated patterns keep the helm charts for a pattern. The helm charts are used to deploy and manage the various components of the applications deployed at a site. By convention, the charts are broken out by site location. You may see datacenter, hub, factory, or other site names in there.
+The site naming convention is flexible, allowing users to modify it to suit their environment.
+Each site has sub-directories based on application or library component groupings.
+From Helm documentation: Application charts are a collection of templates that can be packaged into versioned archives to be deployed.
+Library charts provide useful utilities or functions for the chart developer. They’re included as a dependency of application charts to inject those utilities and functions into the rendering pipeline. Library charts do not define any templates and therefore cannot be deployed.
+These groupings are used by OpenShift GitOps to deploy into the cluster. The configurations for each of the components inside an application are synced every three minutes by OpenShift GitOps to make sure that the site is up to date. The configuration can also be synced manually if you do not wish to wait up to three minutes.
+. ├── datacenter │ ├── external-secrets │ ├── manuela-data-lake │ ├── manuela-tst │ ├── opendatahub │ └── pipelines ├── factory │ └── manuela-stormshift └── secrets └── pipeline-setup The configuration YAML for each component of the application is stored in the templates subdirectory.
+. ├── external-secrets │ ├── Chart.yaml │ ├── templates │ └── values.yaml ├── manuela-data-lake │ ├── Chart.yaml │ ├── templates │ └── values.yaml ├── manuela-tst │ ├── Chart.yaml │ ├── templates │ └── values.yaml ├── opendatahub │ ├── Chart.yaml │ ├── templates │ └── values.yaml └── pipelines ├── Chart.yaml ├── extra ├── images ├── README.md ├── templates └── values.yaml The scripts directory In some cases, an Operator or Helm chart may require additional configuration. When extra code is needed for deployment, it should be placed in the scripts directory. Typically, consumers of a validated pattern won’t interact directly with these scripts, as they are executed by the existing automation (for example through the Makefile or OpenShift GitOps). If extra adjustments are required for your application, place the scripts here and run them through automation. The scripts directory should generally be treated as off-limits unless you’re modifying the framework itself.
+Applications and values- files Helm uses values.yaml files to pass variables into charts. Variables in the values.yaml file can be overridden in the following ways:
+By a values.yaml file in the parent directory
+By a values file passed into the helm &lt;install/upgrade&gt; command using -f
+By specifying an override individual value in the the helm command with --set
+For more information on values files and their usage see the values files section of the Helm documentation.
+This section is meant as an introduction to the values- files that the framework uses to override values in the chart templates. In the Getting Started pages there will be more specific usage details.
+There are three types of value- files. values-global.yaml: This is used to set variables for helm charts across the pattern. It contains the name of the pattern and sets some other variables for artifacts like, image registry, Git repositories, GitOps syncPolicy etc.
+values-&lt;site&gt;.yaml: Each specific site requires information regarding what applications and subscriptions are required for that site. This file contains a list of namespaces, applications, subscriptions, the operator versions etc. for that site.
+values-secret.yaml.template: All patterns require some secrets for artifacts included in the pattern. For example credentials for GitHub, AWS, or Quay.io. The framework provides a safe way to load those secrets into a vault for consumption by the pattern. This template file can be copied to your home directory, the secret values applied, and the validated pattern will go look for values-secrets.yaml in your home directory. Do not leave a values-secrets.yaml file in your cloned git directory or it may end up in your (often public) Git repository, like GitHub.
+This file has nothing to do with helm and can be copied either to your home directory or to the ~/.config/validatedpatterns/ folder. The naming should be values-secret-&lt;pattern-name&gt;.yaml. Ideally it should be encrypted with the ansible-vault.
+Values files can have some overrides. Version overrides can be used to set specific values for OCP versions. For example values-hub-4.16.yaml allows you to tweak a specific value for OCP 4.16 on the Hub cluster.
+Version overrides can be used to set specific values for specific cloud providers. For example values-AWS.yaml would allow you to tweak a specific value for all cluster groups deployed on AWS.
+Other combination examples include: values-hub-Azure.yaml only apply this Azure tweak on the hub cluster.
+values-4.16.yaml apply these OCP 4.16 tweaks to all cluster groups in this pattern.
+Current supported cloud providers include AWS, Azure, GCP, and Nutanix.
+Environment values and Helm The purpose of the values files is to leverage Helm’s templating capabilities, allowing you to dynamically substitute values into your charts. This makes the pattern very portable.
+The following messaging-route.yaml example shows how the AMQ messaging service is using values set in the values-global.yaml file for Industrial Edge.
+apiVersion: route.openshift.io/v1 kind: Route metadata: labels: app: messaging name: messaging spec: host: messaging-manuela-tst-all.apps.{{ .Values.global.datacenter.clustername }}.{{ .Values.global.datacenter.domain }} port: targetPort: 3000-tcp to: kind: Service name: messaging weight: 100 wildcardPolicy: None The values in the values-global.yaml will be substituted when the YAML is applied to the cluster.
+global: pattern: industrial-edge ... datacenter: clustername: ipbabble-dc domain: blueprints.rhecoeng.com edge: clustername: ipbabble-f1 domain: blueprints.rhecoeng.com `,url:"https://validatedpatterns.io/learn/vp_openshift_framework/",breadcrumb:"/learn/vp_openshift_framework/"},"https://validatedpatterns.io/learn/vp_structure_vp_pattern/":{title:"Structuring a validated pattern",tags:[],content:` Creating a validated pattern The high level steps to create a validated pattern are as follows:
+Identify the business case you want to address.
+Use the Multicloud GitOps as a starting point by using the template to create a new Git repository in your local GitHub account.
+Identify the technology components that you need.
+Ensure that the configuration of those components, and the integration points are handled in the pattern.
+Best Practices for creating Validated Patterns Following these best practices, to create robust, scalable, and maintainable validated patterns that are easy to deploy and manage across various environments.
+Start with OpenShift Multicloud GitOps
+When creating a validated pattern, begin with OpenShift Multicloud GitOps as your foundation. This is the most fundamental pattern and should serve as your base.
+Centralize all manifests in a Git Repository
+Ensure that all pattern manifests, configuration files, and desired state definitions are stored in a Git repository. This provides a single source of truth and facilitates the use of GitOps for deployment.
+Include all necessary deployment resources
+The Git repository should include everything required to deploy the pattern, including manifests, configuration, and any additional resources. Avoid relying on manual commands post-deployment; instead, incorporate these into the manifests.
+Adopt a clear separation of concerns
+Maintain a clear separation between configuration files and development source code. This helps manage complexity and ensures that each aspect of the pattern is independently maintainable.
+Leverage GitOps for deployment consistency
+Use GitOps to push the desired state from your Git repository to the Kubernetes cluster. This approach ensures consistency across multiple deployments and clusters.
+Use Helm charts for grouping manifests
+If your deployment process involves multiple oc apply commands, group these manifests into a Helm chart. This simplifies deployment and integrates well with the pattern framework, which can apply the chart automatically.
+Integrate existing automation scripts
+Review existing Ansible scripts or shell scripts that deploy resources. Where possible, convert these scripts into manifests or use the pattern’s framework to apply them imperatively. Avoid adding new scripts, as they often introduce technical debt.
+Ensure comprehensive deployment capabilities
+The pattern should be capable of deploying all necessary resources to support the applications it includes. This means that once the pattern is applied, no additional manual steps should be required.
+Plan for cluster sizing and storage needs
+Before deploying a pattern, review its cluster sizing and storage requirements. For instance, patterns using Red Hat OpenShift Data Foundation (ODF) may require substantial storage resources. Consult pattern documentation for accurate sizing.
+Customize and fork patterns appropriately
+When extending a pattern or deploying it at a customer site, create a personal or organizational fork. This allows for experimentation and customization while facilitating potential contributions back to the upstream pattern repository.
+Consider managed cloud services for deployment
+For ease of deployment, especially in public cloud environments, consider using managed OpenShift services like Red Hat OpenShift Service on AWS (ROSA) or Microsoft Azure Red Hat® OpenShift (ARO). These services simplify the setup and management of OpenShift clusters.
+Manage Multi-Cluster and Multi-Cloud deployments
+Use the patterns framework to centrally manage multiple clusters and workloads across public and private clouds. Incorporate tools like Red Hat Advanced Cluster Management (RHACM) and Red Hat OpenShift GitOps (ArgoCD) to streamline operations.
+Secure secrets across deployments
+Utilize tools such as Hashicorp Vault to manage secrets securely across multi-cloud deployments, ensuring sensitive data is protected.
+`,url:"https://validatedpatterns.io/learn/vp_structure_vp_pattern/",breadcrumb:"/learn/vp_structure_vp_pattern/"},"https://validatedpatterns.io/learn/vp_agof/":{title:"Ansible GitOps Framework",tags:[],content:` About the Ansible GitOps framework (AGOF)for validated patterns The Ansible GitOps Framework provides an extensible framework to do GitOps with Ansible Automation Platform (AAP). It offers useful facilities for developing patterns (community and validated) that work with AAP as the GitOps engine.
+When there is no access to OpenShift Container Platform, AGOF provides a standalone solution for deploying and managing validated patterns. This framework leverages GitOps principles without relying on OpenShift.
+Administrators can use the Ansible Automation Platform, which includes automation controller, a web-based UI interface to define, operate, scale, and delegate automation across their enterprise.
+The repository at Ansible GitOps Framework provides code for installing VMs on AWS, if needed. It can also be used with existing VMs or a functional AAP Controller endpoint.
+The Ansible GitOps Framework repository contains code to set up the infrastructure for applying controller_configuration to an AAP instance. It includes some predefined configurations and practices to make the infrastructure as code repository more user-friendly and standardized. An AGOF pattern for example demo is primarily an IaC infrastructure as code (IaC) artifact designed to be used with the controller_configuration collection.
+Role of the Ansible Controller In the Ansible GitOps framework, the Ansible Controller refers to any machine that initiates and runs playbooks. This includes systems running Ansible Core or open source Ansible, where the machine executing the playbooks also acts as the controller. The Ansible Automation Platform (AAP) provides the Automation Controller, which is Red Hat’s productized Ansible Controller.
+The Automation controller is the command and control center for Red Hat Ansible Automation Platform, replacing Ansible Tower. It includes a web UI, API, role-based access control (RBAC), a workflow visualizer, and continuous integration and continuous delivery (CI/CD) integrations to help you organize and manage automation across your enterprise.
+The Automation Controller serves as the centralized platform for managing and executing automation across infrastructure. Use the Automation Controller to create job templates that standardize the deployment and execution of Ansible playbooks, making automation more consistent and reusable. It integrates essential components such as execution environments for consistent automation execution, projects (repositories for automation content), inventories (target endpoints), and credentials (for secure access to resources).
+The webUI provides an intuitive interface to build, monitor, and manage automation workflows, while the API offers seamless integration with other tools, such as CI/CD pipelines or orchestration platforms. Overall, the Automation Controller streamlines the automation lifecycle, ensuring a scalable, secure, and maintainable automation environment.
+Ansible framework methods The main methods for setting up an Ansible framework are as follows:
+The focus here is primarily on the AWS-based installation method.
+AWS based install This method is ideal for organizations deploying AAP on AWS infrastructure. In AAP 2.4, the default installation process uses AWS and offers a fully automated setup. It requires AWS credentials and builds an AWS image with Red Hat’s ImageBuilder, setting up AAP within an AWS VPC and subnet. The installation program creates all necessary resources, including AAP Controllers and, optionally, additional components such as the Automation Hub.
+This is the easiest method if you already use AWS, as it automates the provisioning of resources, including VMs and network configurations. This requires AWS infrastructure and credentials.
+Custom Ansible controller (API install) In this method, you provide an existing Ansible Automation Platform (AAP) Controller endpoint, either on bare metal or in a private cloud, without needing AWS or pre-configured VMs. You specify the manifest, endpoint hostname, admin credentials, and pass the installation process to a predefined controller_config_dir. This is suitable for complex or custom topologies where you want full control over the deployment.
+This method provides maximum flexibility and is designed for advanced users who have their own AAP installations, either on-prem or in complex environments that do not fit into the default or AWS-centric model. You need an existing AAP controller, which might not be ideal for users new to AAP or those looking for more hands-off installation
+Creating a validated pattern using the AGOF framework To deploy a validated pattern, follow these steps:
+Clone the Ansible GitOps Framework Minimal Configuration Demo repository by running the following command:
+$ git clone git@github.com:mhjacks/agof_demo_config.git This is a minimal pattern that demonstrates how to use the Ansible GitOps Framework.
+Clone the AGOF repository by running the following command.
+$ git clone git@github.com:validatedpatterns/agof.git This serves as the provisioner for the pattern
+Deploying using the AWS-based install method This method:
+Builds an AWS image using Red Hat’s ImageBuilder.
+Deploys that image onto a new AWS VPC and subnet.
+Deploys AAP on that image using the command line installer.
+Hands over the configuration of the AAP installation to the specified agof_controller_config_dir.
+Prerequisites You need to provide some key information to a file named agof_vault.yml created in your home directory. The key pieces of information needed are:
+The name of a hosted zone created under Route 53 in AWS. For example this could be aws.validatedpatterns.io.
+Your AWS account Account ID
+Your aws key
+Your secret access key
+Procedure Copy the agof_vault_template.yml from the cloned agof directory to your home directory and rename it agof_vault.yml.
+$ cp ~/agof/agof_vault_template.yml ~/agof_vault.yml Table 1. Agof vault settings Argument Description aws_account_nbr_vault
+Your AWS account number. This is needed for sharing composer images.
+aws_access_key_vault
+Your AWS access key.
+aws_secret_key_vault
+Your AWS secret key.
+pattern_prefix
+A unique prefix to distinguish instances in AWS. Used as the pattern name and in public DNS entries.
+ec2_region
+An AWS region that your account has access to.
+offline_token
+A Red Hat offline token used to build the RHEL image on console.redhat.com.
+Click the GENERATE TOKEN link at Red Hat API Tokens to create the token.
+redhat_username
+Red Hat Subscription username, used to log in to registry.redhat.io.
+redhat_password
+Red Hat Subscription password, used to log in to registry.redhat.io.
+admin_password
+An admin password for AAP Controller and Automation Hub.
+manifest_content
+Content for a manifest file to entitle AAP Controller. See below for an example of how to point to a local file.
+org_number_vault
+The Organization Number (Org ID) attached to your Red Hat Subscription for RHEL and AAP.
+activation_key_vault
+The name of an Activation Key to embed in the imagebuilder image.
+Click the Create Activation Keys link at console.redhat.com &gt; Red Hat Enterprise Linux &gt; Inventory &gt; System Configuration &gt; Activation Keys to create an activation key.
+skip_imagebuilder_build
+Set these variables to provide your own AMI, or to re-use an AMI previously generated with this process. When a previously built AMI is found this check does not take place. #imagebuilder_ami: &#39;The ID of an AWS AMI image, preferably one that was built with this toolkit&#39;
+automation_hub_token_vault
+A token associated with your AAP subscription used to retrieve Automation Hub content.
+Click the Load token link at console.redhat.com &gt; Ansible Automation Platform &gt; Automation Hub &gt; Connect to Hub to generate a token.
+automation_hub_url_certified_vault
+Optional: The private automation hub URL for certified content.
+automation_hub_url_validated_vault
+Optional: The private automation hub URL for validated content.
+Edit the file and add the following:
+agof_controller_config_dir: set it’s value to {{ &#39;~/agof_minimal_demo&#39; | expanduser }}.
+db_password: sets an appropriate value for the postgres password for the DB instance for example test.
+agof_statedir: set its value to &#34;{{ &#39;~/agof&#39; | expanduser }}&#34;
+agof_iac_repo: set its value to &#34;https://github.com/mhjacks/agof_demo_config.git&#34;
+Optional: Create a subscription manifest by following the guidance at Obtaining a manifest file.
+Update your agof_vault.yml file with the path to the downloaded manifest zip file. For example add the following:
+controller_license_src_file: &#39;~/Downloads/&lt;manifest_filename&gt;.zip&#39; manifest_content: &#34;{{ lookup(&#39;file&#39;, controller_license_src_file) | b64encode }}&#34; Example agof_vault.yml file --- aws_account_nbr_vault: &#39;&lt;AWS_account_ID&gt;&#39; aws_access_key_vault: &#39;&lt;AWS_access_key&gt;&#39; aws_secret_key_vault: &#39;&lt;AWS_secret_key&gt;&#39; pattern_prefix: &#39;foga&#39; pattern_dns_zone: &#39;aws.validatedpatterns.io&#39; ec2_name_prefix: &#39;foga-testing&#39; ec2_region: &#39;us-east-1&#39; offline_token: &#39;&lt;insert-token-here&gt;&#39; redhat_username: &#39;rhn-support-myusername&#39; redhat_password: &#39;passwd01&#39; admin_password: &#39;redhat123!&#39; manifest_content: &#34;Content for a manifest file to entitle AAP Controller. See below for an example of how to point to a local file&#34; #manifest_content: &#34;{{ lookup(&#39;file&#39;, &#39;~/Downloads/manifest_AVP_20230510T202608Z.zip&#39;) | b64encode }}&#34; org_number_vault: &#34;&lt;Org-ID&gt;&#34; activation_key_vault: &#34;kevs-agof-key&#34; # Set these variables to provide your own AMI, or to re-use an AMI previously generated with this process #skip_imagebuilder_build: &#39;boolean: skips imagebuilder build process&#39; #imagebuilder_ami: &#39;The ID of an AWS AMI image, preferably one that was built with this toolkit&#39; automation_hub_token_vault: &#39;&lt;insert-token-here&gt;&#39; # These variables can be set but are optional. The previous (before AAP 2.4) conncept of sync-list was private # to an account. #automation_hub_url_certified_vault: &#39;The private automation hub URL for certified content&#39; #automation_hub_url_validated_vault: &#39;The private automation hub URL for validated content&#39; controller_config_dir: &#34;{{ &#39;~/agof_minimal_demo&#39; | expanduser }}&#34; db_password: &#39;test&#39; agof_statedir: &#34;{{ &#39;~/agof&#39; | expanduser }}&#34; agof_iac_repo: &#34;https://github.com/mhjacks/agof_demo_config.git&#34; Run the following command from the AGOF repository directory:
+$ ./pattern.sh make install This command invokes the controller_configuration dispatch role on the controller endpoint based on the configuration found in the controller_configuration_dir and in your agof_vault.yml file. This controls all of the controller configuration. Based on the variables defined in the controller configuration, dispatch calls the necessary roles and modules in the right order to configure AAP to run your pattern.
+Verification The default installation provides an AAP 2.4 installation deployed using the containerized installer, with services deployed this way:
+Table 2. agof_vault settings URL Service https:{{ ec2_name_prefix }}.{{ domain }}:8443
+Controller API.
+https:{{ ec2_name_prefix }}.{{ domain }}:8444/
+Private Automation Hub
+https:/{{ ec2_name_prefix }}.{{ domain }}:8445/\`
+EDA Automation Controller
+Once the install completes, you will have a project, an inventory (consisting of the AAP controller), a credential (the private key from ec2), a job template (which runs a fact gather on the AAP controller) and a schedule that will run the job template every 5 minutes,
+Log in to https://aap.{{ ec2_name_prefix }}.{{ domain }}:8443 with the username admin and the password as configured in admin_password field of agof_vault.yml.
+Under Resources &gt; Projects verify the project Ansible GitOps Framework Minimal Demo is created with status Successful.
+Under Resources &gt; Inventories verify the inventory AGOF Demo Inventory is created with sync status Success.
+Under Resources &gt; Templates verify the job template Ping Playbook is created.
+Under Resources &gt; Credentials verify the ec2 ssh credential ec2_ssh_credential is created.
+Under Views &gt; Schedules verify the schedules are created.
+Custom Ansible controller (API install) In this method, you provide an existing Ansible Automation Platform (AAP) Controller endpoint, either on bare metal or in a private cloud, without needing AWS or pre-configured VMs.
+You supply the manifest contents, endpoint hostname, admin username (defaults to &#34;admin&#34;), and admin password, and then the installation hands off to a controller_config_dir you define.
+Run the following command to install using this method:
+$ ./pattern.sh make api_install Tearing down the installation To tear down the installation run the following command:
+$ ./pattern.sh make aws_uninstall `,url:"https://validatedpatterns.io/learn/vp_agof/",breadcrumb:"/learn/vp_agof/"},"https://validatedpatterns.io/learn/vp_agof_config_controller/":{title:"Using the Controller Configuration collection",tags:[],content:` Overview of the Ansible GitOps Framework (AGOF) Installation Process The Ansible GitOps Framework (AGOF) is a powerful solution designed to automate the deployment and configuration of Ansible Automation Platform (AAP) environments using GitOps principles. It leverages Ansible to manage infrastructure and application provisioning in a declarative, version-controlled way. AGOF provides a structured approach to setting up cloud infrastructure, installing AAP components, and handing over control to the AAP Controller for ongoing automation and management. An overview of the steps involved in configuring a basic demo minimal demo application are listed here:
+1. Pre-Init Environment (Bootstrap Ansible) Ansible Configuration: The environment is initialized by generating an ansible.cfg file, which is configured with Automation Hub and public Galaxy endpoints. This process includes vault configuration to inject the Automation Hub token and install required Ansible collections from requirements.yml.
+Optional Image Build: Images are created using Red Hat Image Builder to produce AMIs, which include cloud-init, activation keys, and organization details. These images can be reused in future installations.
+2. Infrastructure Building (AWS Only) AWS Setup: The framework sets up AWS infrastructure, including VPC, subnets, and security groups, using predefined roles. It also manages Route53 DNS entries for VMs.
+VM Deployment: Virtual machines are provisioned on EC2 with persistent hostnames and updates to /etc/hosts for AWS nodes. DNS entries are updated when IPs change after VM reboots.
+3. Handover to Ansible Controller Controller Setup: The Ansible Automation Platform (AAP) Controller and optionally the Automation Hub are installed and configured. Entitlements are managed through a manifest, and execution environments and collections are downloaded and prepared.
+GitOps Mode: After configuration, AGOF transitions to GitOps mode. GGit commits made by the controller to the repositories manage all environment changes, ensuring declarative and automated infrastructure management from this point onward.
+Controller configuration collection An AGOF pattern, for example, https://github.com/mhjacks/agof_demo_config is primarily an IaC (infrastructure as code) artifact designed to be used with the controller_configuration collections.
+The AGOF (Ansible GitOps Framework) repository https://github.com/validatedpatterns/agof contains the code and tools needed to set up a new Ansible Automation Platform (AAP) instance. This setup is automated, using Infrastructure as Code (IaC) practices. It also includes some specific preferences to make it easier for others to publicly share and manage this type of infrastructure setup.
+This approach ensures the automation controller configuration is version-controlled, dynamic, and reproducible. This method enables deployment automation with minimal manual intervention, which is useful for managing multiple controller instances or different environments in a CI/CD pipeline.
+For example, for the AGOF minimal configuration demo the file https://github.com/mhjacks/agof_demo_config/blob/main/controller_config.yml is used with Ansible’s Controller Configuration Collection, allowing the automation and management of Red Hat Ansible Automation Controller (formerly known as Ansible Tower).
+# vim: ft=yaml.ansible --- orgname_vault: &#39;Demo Organization&#39; controller_username_vault: &#39;admin&#39; controller_password_vault: &#39;{{ admin_password }}&#39; controller_username: &#39;{{ controller_username_vault }}&#39; controller_password: &#39;{{ controller_password_vault }}&#39; agof_demo_project_name: &#39;Ansible GitOps Framework Minimal Demo&#39; controller_validate_certs: false controller_configuration_async_retries: 30 controller_settings: [] controller_projects: - name: Demo Project state: absent - name: &#39;{{ agof_demo_project_name }}&#39; organization: &#34;{{ orgname_vault }}&#34; scm_branch: main scm_clean: &#34;no&#34; scm_delete_on_update: &#34;no&#34; scm_type: git scm_update_on_launch: &#34;yes&#34; scm_url: &#39;https://github.com/validatedpatterns-demos/agof_minimal_demo.git&#39; controller_organizations: - name: &#39;{{ orgname_vault }}&#39; controller_inventories: - name: &#39;AGOF Demo Inventory&#39; organization: &#39;{{ orgname_vault }}&#39; controller_inventory_sources: - name: &#39;AGOF Demo Inventory Source&#39; inventory: &#39;AGOF Demo Inventory&#39; credential: &#39;ec2_ssh_credential&#39; overwrite: true overwrite_vars: true update_on_launch: true source: scm source_project: &#39;{{ agof_demo_project_name }}&#39; source_path: &#39;inventory&#39; controller_credential_types: [] controller_templates: - name: Demo Job Template state: absent - name: Ping Playbook organization: &#34;{{ orgname_vault }}&#34; project: &#39;{{ agof_demo_project_name }}&#39; job_type: run playbook: &#39;ansible/playbooks/ping.yml&#39; inventory: &#34;AGOF Demo Inventory&#34; credentials: - ec2_ssh_credential controller_schedules: - name: Ping Playbook organization: &#34;{{ orgname_vault }}&#34; unified_job_template: Ping Playbook rrule: DTSTART:20191219T130500Z RRULE:FREQ=MINUTELY;INTERVAL=120 demo_ssh_key_file: &#39;~/{{ ec2_name_prefix }}/{{ ec2_name_prefix }}-private.pem&#39; controller_credentials: - name: ec2_ssh_credential description: &#34;EC2 SSH credential&#34; organization: &#39;{{ orgname_vault }}&#39; credential_type: Machine inputs: username: &#39;ec2-user&#39; ssh_key_data: &#34;{{ lookup(&#39;file&#39;, demo_ssh_key_file) }}&#34; become_method: sudo controller_launch_jobs: - name: Ping Playbook organization: &#34;{{ orgname_vault }}&#34; This file automates the creation, updating, or deletion of Ansible Controller objects (organizations, projects, inventories, credentials, templates, schedules). Sensitive information like passwords and keys are pulled dynamically from vaults, ensuring they are not hardcoded in the configuration.
+A Git repository manages the project’s inventory and playbooks, allowing for continuous integration and delivery (CI/CD) practices. AAP automatically schedules recurring playbook executions, eliminating the need for manual job triggers.
+Key sections and parameters This section describes the parameters associated with the Ansible GitOps Framework minimal configuration demo.
+Vault variables orgname_vault: &#39;Demo Organization&#39; This specifies the organization name stored in a vault for security purposes.
+controller_username_vault: &#39;admin&#39; This is the Ansible Controller’s username stored in a vault.
+controller_password_vault: &#39;{{ admin_password }}&#39; The initial admin password that AAP is configured with to allow the controller_username to log in. This particular password is not retrieved from a vault.
+Dynamic variables controller_username: &#39;{{ controller_username_vault }}&#39; The Ansible Controller username is retrieved from the vault variable.
+controller_password: &#39;{{ controller_password_vault }}&#39; The password is dynamically fetched from the vault.
+Project configuration Projects are git repositories that can contain inventories and collections (and collections can contain playbooks).
+agof_demo_project_name: &#39;Ansible GitOps Framework Minimal Demo&#39; This variable holds the name of the project being managed in the controller.
+controller_projects Two projects are defined:
+One with the name &#39;Demo Project&#39;, marked for deletion (state: absent).
+The other is the actual project that will be created, associated with the Git repository hosted on GitHub.
+For more information see, controller_configuration.projects.
+Organizations Organizations represent a logical grouping for managing resources such as projects and inventories.
+controller_organizations Ensures that the organization, defined in orgname_vault, exists within the controller. For more information see, controller_configuration.organizations.
+Inventory and inventory sources controller_inventories Defines an inventory called &#39;AGOF Demo Inventory&#39; under the &#39;Demo Organization&#39;. For more information see, controller_configuration.inventories.
+controller_inventory_sources Configures an inventory source tied to the Git project. The inventory is pulled from source control management (SCM) and associated with credentials for SSH access (ec2_ssh_credential). For more information see, controller_configuration.inventory_sources.
+Job templates Job Templates define a specific playbook run, associating it with inventories, credentials, and other settings.
+controller_templates Two job templates are managed:
+One named &#39;Demo Job Template&#39;, marked for deletion.
+The other, &#39;Ping Playbook&#39;, is tied to a specific playbook (ping.yml), inventory, and project, and will use the defined credentials for execution.
+For more information see, controller_configuration.job_templates.
+Job scheduling controller_schedules Configures a recurring job schedule to run the &#39;Ping Playbook&#39; template every 120 minutes. The schedule uses an iCal RRULE format. For more information see, controller_configuration.schedules.
+Credentials Credentials store authentication details for accessing external systems like clouds, networks, and SCMs.
+controller_credentials A credential named &#39;ec2_ssh_credential&#39; is created with SSH access to the EC2 instances using the private key stored at the path specified in demo_ssh_key_file. For more information see, controller_configuration.credentials.
+Job Launching controller_launch_jobs Automatically launches the &#39;Ping Playbook&#39; job template within the organization defined in orgname_vault. For more information see, controller_configuration.job_launch.
+For more information about the controller configuration see:
+Red Hat Automation Controller Admin Guide
+Red Hat Communities of Practice Controller Configuration Collection
+Galaxy Red Hat Communities of Practice Controller Configuration Collection documentation
+`,url:"https://validatedpatterns.io/learn/vp_agof_config_controller/",breadcrumb:"/learn/vp_agof_config_controller/"},"https://validatedpatterns.io/patterns/industrial-edge/application/":{title:"Application Demos",tags:[],content:`Demonstrating Industrial Edge example applications Background Up until now the Industrial Edge 2.0 validated patterns has focused primarily on successfully deploying the architectural pattern. Now it is time to see GitOps and DevOps in action as we go through a number of demonstrations to change both configuration information and the applications that we are deploying.
+If you have already deployed the data center and optionally a factory (edge) cluster, then you have already seen several applications deployed in the OpenShift GitOps console. If you haven&rsquo;t done this then we recommend you deploy the data center after you have setup the Quay repositories described below.
+Prerequisite preparation Quay public registry setup In the Quay.io registry please ensure you have the following repositories and that they are set for public access. Replace your-org with the name of your organization or Quay.io username.
+your-org/iot-software-sensor your-org/iot-consumer your-org/iot-frontend your-org/iot-anomaly-detection your-org/http-ionic These repositories are needed in order to provide container images built at the data center to be consumed by the factories (edge).
+Local laptop/workstation Make sure you have git and OpenShift&rsquo;s oc command-line clients.
+OpenShift Cluster Make sure you have the kubeadmin administrator login for the data center cluster. Use this or the kubeconfig (export the path) to provide administrator access to your data center cluster. It is not required that you have access to the edge (factory) clusters. GitOps and DevOps will take care of the edge clusters.
+GitHub account You will need to login into GitHub and be able to fork two repositories.
+validatedpatterns/industrial-edge validatedpatterns-demos/manuela-dev Configuration changes with GitOps There will may be times where you need to change the configuration of some of the edge devices in one or more of your factories. In our example, we have various sensors at the factory. Modification can be made to these sensors using ConfigMaps.
+In this demonstration we will turn on a temperature sensor for sensor #2. We will first do this in the data center because this will demonstrate the power of GitOps without having to involve the edge/factory. However if you do have an factory joined using Advanced Cluster Management, then the changes will make their way out to the factory. But it is not necessary for the demo as we have a complete test environment on the data center.
+Make sure you are able to see the dashboard application in a tab on your browser. You can find the URL for the dashboard application by looking at the following in your OpenShift console.
+Select Networking-&gt;Routes on the left-hand side of the console. Using the Projects pull-down, select manuela-tst-all. Click on the URL under the Location column for the route Name line-dashboard. this will launch the line-dashboard monitoring application in a browser tab. The URL will look like:
+line-dashboard-manuela-tst-all.apps.*cluster-name*.*domain*
+Once the the application is open in your browser, click on the “Realtime Data” Navigation on the left and wait a bit. Data should be visualized as received. Note that there is only vibration data shown! If you wait a bit more (usually every 2-3 minutes), you will see an anomaly and alert on it.
+Now let&rsquo;s turn on the temperature sensor. Using you favorite editor, edit the following file:
+industrial-edge/charts/data-center/manuela-test/templates/machine-sensor/machine-sensor-2-configmap.yaml Change SENSOR_TEMPERATURE_ENABLED: &quot;false&quot; to SENSOR_TEMPERATURE_ENABLED: &quot;true&quot;.
+Then change and commit this to your git repository so that the change will be picked up by OpenShift GitOps (ArgoCD).
+git add industrial-edge-charts/data/center/manuela-test/templates/machine-sensor/machine-sensor-2-configmap.yaml git commit -m &#34;Turned on temprature sensor for machine sensor #2&#34; git push You can track the progress of this commit/push in your OpenShift GitOps console in the manuela-test-all application. You will notice components regarding machine-sensor-2 getting sync-ed. You can speed this up by manually pressing the Refresh button.
+The dashboard app should pickup the change automatically, once data from the temperature sensor is received. Sometimes a page/tab refreshed is needed for the change to be picked up.
+Application changes using DevOps The line-dashboard application has temperature sensors. In this demonstration we are going to make a simple change to that application, rebuild and redeploy it. In the manuela-dev repository there is a file components/iot-consumer/index.js. This JavaScript program consumes message data coming from the line servers and one of functions it performs is to check the temperature to see if it has exceeded a threshold. There is three lines of code in there that does some Celsius to Fahrenheit conversion.
+Depending on the state of your manuela-dev repository this may or may not be commented out. Ideally for the demonstration you would want it uncommented and therefore effective. What this means is that while the labels on the frontend application are showing Celsius, the data is actually in Fahrenheit. This is a good place to start because that data won&rsquo;t make any sense.
+Machines running over 120C is not normal. However examining the code explains why. There is an erroneous conversion taking place. What must happen is we remove or comment out this code.
+If you haven&rsquo;t deployed the uncommented code it might be best to prepare that before the demonstration. After pointing out the problem, comment out the code.
+Now that the erroneous conversion code has been commented out it is is time rebuild and redeploy. First commit and push the code to the repository. While in the directory for your manuela-dev repository run the following commands. The components/iot-consumer/index.js file should be the only changed file.
+git add components/iot-consumer/index.js git commit -m &#34;commented out C to F temp conversion&#34; git push Now its time to kick off the CI pipeline. Due to the need for GitHub secrets and Quay secrets as part of this process, we currently can&rsquo;t use the OpenShift console&rsquo;s Pipelines to kick off the pipeline in the demo environment. Instead, use the command-line. While in the industrial-edge repository directory, run the following:
+make build-and-test This build takes some time because the pipeline is rebuilding all the images. You can monitor the pipeline&rsquo;s progress in the Openshift console&rsquo;s pipelines section.
+Alternatively you can can try and run the shorter build-iot-consumer pipeline run in the OpenShift console. This should just run and test the specific application.
+You can also see some updates happening in the manuela-tst application in OpenShift GitOps (ArgoCD).
+When the pipeline is complete check the lines-dashboard application again in the browser. More reasonable, Celsius, temperatures are displayed. (Compare with above.)
+The steps above have successfully applied the change to the Manuela test environment at the data center. In order for these changes to be pushed out to the factories it must be accepted and pushed to the Git repository. Examine the project in GitHub. There is a new Pull Request (PR) called Pull request created by Tekton task github-add-pull-request. Select that PR and merge the pull request.
+OpenShift GitOps will see the new change and apply it out to the factories.
+Application AI model changes with DevOps After a successful deployment of Industrial Edge 2.0, check to see that Jupyter Hub is running. To do this go to project manuela-ml-workspace check that jupyterhub pods are up and running.
+Then, in the same project manuela-ml-namespace, select Networking/Routes and click on the URL associated with jupyterhub in the Location column.
+This will bring you to a web page at an address in the following format:
+jupyterhub-manuela-ml-workspace.apps.*clustername*.*your-domain* Options for different types of Jupyter servers are shown. There are two options that are useful for this demo.
+Standard Data Science. Select this notebook image for simpler notebooks like Data Analyses.ipynb Tensorflow Notebook Image. Select this notebook image for more a complex notebook that require Tensorflow. E.g. Anomaly Detection-using-TF-and-Deep-Learning.ipynb At the bottom of the screen there is a Start server button. Select the type of Notebook server image and press Start server.
+Selecting Tensorflow notebook image:
+On the next screen upload the following files from manuela-dev/ml-models/anomaly-detection:
+One of the Jupyter notebooks Data-Analyses.ipynb for a somewhat simpler demo Anomaly Detection-using-TF-and-Deep-Learning.ipynb for a Tensorflow demo. raw-data.cvs Open the notebook by double clicking on the notebook file (ending in .ipynb)
+After opening the notebook successfully, walk through the demonstration by pressing play and iterating through the commands in the playbook. Jupyter playbooks are interactive and you may make changes and also save those changes. Also, some steps in the notebook take milliseconds, however, other steps can take a long time (up to an hour), so check on the completion of steps.
+Remember that changes to the notebook will require downloading, committing, and pushing that notebook to the git repository so that it gets redeployed to the factories.
+`,url:"https://validatedpatterns.io/patterns/industrial-edge/application/",breadcrumb:"/patterns/industrial-edge/application/"},"https://validatedpatterns.io/patterns/retail/application/":{title:"Application Demos",tags:[],content:`Demonstrating Retail example applications Background Up until now the Retail validated pattern has focused primarily on successfully deploying the architectural pattern. Now it is time to see the actual applications running as we have deployed them.
+If you have already deployed the hub cluster, then you have already seen several applications deployed in the OpenShift GitOps console. If you haven&rsquo;t done this then we recommend you deploy the hub after you have setup the Quay repositories described below.
+Ordering Items at the Coffeeshop The easiest way to get to the coffeeshop store page is from the OpenShift Console Menu Landing Page entry:
+Clicking on the Quarkus Coffeeshop Landing Page link will bring you to this page:
+And clicking on either the &ldquo;Store Web Page&rdquo; or &ldquo;TEST Store Web Page&rdquo; links will bring you to a screen that looks like this:
+NOTE: The applications are initially identical. The &ldquo;TEST&rdquo; site is deployed to the quarkuscoffeeshop-demo namespace; the regular Store site is deployed to the quarkuscoffeeshop-store namespace.
+Each store requires supporting services, in PostgreSQL and Kafka. In our pattern, PostgreSQL is provided by the Crunchy PostgreSQL operator, and Kafka is provided by the Red Hat AMQ Streams operator. Each instance, the regular instance and the TEST instance, has its own instance of each of these supporting services it uses.
+To order, click on the &ldquo;Place an Order&rdquo; button on the front page. The menu should look like this:
+Click the &ldquo;Add&rdquo; button next to a menu item; the item name will appear. Add a name for the order:
+You can add as many orders as you want. On your last item, click the &ldquo;Place Order&rdquo; button on the item dialog:
+As the orders are serviced by the barista and kitchen services, you can see their status in the &ldquo;Orders&rdquo; section of the page:
+`,url:"https://validatedpatterns.io/patterns/retail/application/",breadcrumb:"/patterns/retail/application/"},"https://validatedpatterns.io/patterns/multicloud-gitops-amx/mcg-amx-cluster-sizing/":{title:"Cluster sizing",tags:[],content:` About OpenShift cluster sizing for the Intel AMX accelerated Multicloud GitOps pattern The minimum requirements for an OpenShift Container Platform cluster depend on your installation platform, for example:
+For AWS, see Installing OpenShift Container Platform on AWS.
+For bare-metal, see Installing OpenShift Container Platform on bare metal.
+To understand cluster sizing requirements for the Intel AMX accelerated Multicloud GitOps pattern, consider the following components that the Intel AMX accelerated Multicloud GitOps pattern deploys on the datacenter or the hub OpenShift cluster:
+Name Kind Namespace Description multicloud-gitops-amx-hub
+Application
+multicloud-gitops-amx-hub
+Hub GitOps management
+Red Hat Advanced Cluster Management
+Operator
+open-cluster-management
+Advance Cluster Management
+Red Hat OpenShift GitOps
+Operator
+openshift-operators
+OpenShift GitOps
+Node Feature Discovery
+Operator
+openshift-nfd
+Manages the detection and labeling of hardware features and configuration (for example Intel AMX)
+Red Hat OpenShift Data Foundation
+Operator
+openshift-storage
+Cloud Native storage solution
+The Intel AMX accelerated Multicloud GitOps pattern also includes the Red Hat Advanced Cluster Management (RHACM) supporting operator that is installed by OpenShift GitOps using Argo CD.
+Intel AMX accelerated Multicloud GitOps pattern with OpenShift clusters sizes The datacenter hub OpenShift cluster needs to be a bit bigger than the Factory/Edge clusters because this is where the developers will be running pipelines to build and deploy the Intel AMX accelerated Multicloud GitOps pattern on the cluster. The above cluster sizing is close to a minimum size for a Datacenter HUB cluster. In the next few sections we take some snapshots of the cluster utilization while the Intel AMX accelerated Multicloud GitOps pattern is running. Keep in mind that resources will have to be added as more developers are working building their applications.
+The recommended clusters sizes for datacenter hub and for managed datacenter are the same in this case:
+Node type Number of nodes CPU Memory Storage Control Planes
+3
+2x 5th Generation Intel Xeon Gold 6526Y (16 cores at 2.8 GHz base with Intel AMX) or better
+128 GB (8 x 16 GB DDR5 4800) or more
+NVME SSD 3TB or more
+Workers
+3
+2x 5th Generation Intel Xeon Gold 6538Y+ (32 cores at 2.2 GHz base with Intel AMX) or better
+256 GB (16 x 16 GB) or 512 GB (16 x 32GB) DDR5-4800
+NVME SSD 3TB or more
+You might want to add resources when more developers are working on building their applications.
+The pattern was tested in the on-premises environment with following hardware configuration (per cluster):
+Node type Number of nodes CPU Memory Storage Control Planes + Workers
+3 + 3
+2x 5th Generation Intel Xeon Platinum 8568Y+ (48 cores at 2.3 GHz base with Intel AMX)
+512 GB (16x32GB DDR5 5600)
+4x 3.84TB U.2 NVMe PCIe Gen4
+`,url:"https://validatedpatterns.io/patterns/multicloud-gitops-amx/mcg-amx-cluster-sizing/",breadcrumb:"/patterns/multicloud-gitops-amx/mcg-amx-cluster-sizing/"},"https://validatedpatterns.io/patterns/multicloud-gitops-qat/mcg-qat-cluster-sizing/":{title:"Cluster sizing",tags:[],content:` About OpenShift cluster sizing for the Intel QAT accelerated Multicloud GitOps pattern The minimum requirements for an OpenShift Container Platform cluster depend on your installation platform, for example:
+For AWS, see Installing OpenShift Container Platform on AWS.
+For bare-metal, see Installing OpenShift Container Platform on bare metal.
+To understand cluster sizing requirements for the Intel QAT accelerated Multicloud GitOps pattern, consider the following components that the Intel QAT accelerated Multicloud GitOps pattern deploys on the datacenter or the hub OpenShift cluster:
+Name Kind Namespace Description multicloud-gitops-qat-hub
+Application
+multicloud-gitops-qat-hub
+Hub GitOps management
+Red Hat Advanced Cluster Management
+Operator
+open-cluster-management
+Advance Cluster Management
+Red Hat OpenShift GitOps
+Operator
+openshift-operators
+OpenShift GitOps
+Node Feature Discovery
+Operator
+openshift-nfd
+Manages the detection and labeling of hardware features and configuration (for example Intel QAT)
+Red Hat OpenShift Data Foundation
+Operator
+openshift-storage
+Cloud Native storage solution
+Intel Device Plugin®
+Operator
+inteldeviceplugin
+Manages Intel hardware feature-provisioning
+Sail Operator
+Operator
+istio-system
+Istio Service Mesh solution
+The Intel QAT accelerated Multicloud GitOps pattern also includes the Red Hat Advanced Cluster Management (RHACM) supporting operator that is installed by OpenShift GitOps using Argo CD.
+Intel QAT accelerated Multicloud GitOps pattern with OpenShift clusters sizes The datacenter hub OpenShift cluster needs to be a bit bigger than the Factory/Edge clusters because this is where the developers will be running pipelines to build and deploy the Intel QAT accelerated Multicloud GitOps pattern on the cluster. The above cluster sizing is close to a minimum size for a Datacenter HUB cluster. In the next few sections we take some snapshots of the cluster utilization while the Intel QAT accelerated Multicloud GitOps pattern is running. Keep in mind that resources will have to be added as more developers are working building their applications.
+The recommended clusters sizes for datacenter hub and for managed datacenter are the same in this case:
+Node type Number of nodes CPU Memory Storage Control Planes
+3
+2x 5th Generation Intel Xeon Gold 6526Y (16 cores at 2.8 GHz base with Intel SGX) or better
+128 GB (8 x 16 GB DDR5 4800) or more
+NVME SSD 3TB or more
+Workers
+3
+2x 5th Generation Intel Xeon Gold 6538Y+ (32 cores at 2.2 GHz base with Intel SGX) or better
+256 GB (16 x 16 GB) or 512 GB (16 x 32GB) DDR5-4800
+NVME SSD 3TB or more
+You might want to add resources when more developers are working on building their applications.
+The pattern was tested in the on-premises environment with following hardware configuration (per cluster):
+Node type Number of nodes CPU Memory Storage Control Planes + Workers
+3 + 3
+2x 5th Generation Intel Xeon Platinum 8568Y+ (48 cores at 2.3 GHz base with Intel SGX)
+512 GB (16x32GB DDR5 5600)
+4x 3.84TB U.2 NVMe PCIe Gen4
+`,url:"https://validatedpatterns.io/patterns/multicloud-gitops-qat/mcg-qat-cluster-sizing/",breadcrumb:"/patterns/multicloud-gitops-qat/mcg-qat-cluster-sizing/"},"https://validatedpatterns.io/patterns/multicloud-gitops-sgx-hello-world/mcg-sgx-hello-world-cluster-sizing/":{title:"Cluster sizing",tags:[],content:` About OpenShift cluster sizing for the Intel SGX protected application in Multicloud GitOps pattern The minimum requirements for an OpenShift Container Platform cluster depend on your installation platform, for example:
+For AWS, see Installing OpenShift Container Platform on AWS.
+For bare-metal, see Installing OpenShift Container Platform on bare metal.
+To understand cluster sizing requirements for the Intel SGX protected application in Multicloud GitOps pattern, consider the following components that the Intel SGX protected application in Multicloud GitOps pattern deploys on the datacenter or the hub OpenShift cluster:
+Name Kind Namespace Description multicloud-gitops-sgx-hello-world-hub
+Application
+multicloud-gitops-sgx-hello-world-hub
+Hub GitOps management
+Red Hat Advanced Cluster Management
+Operator
+open-cluster-management
+Advance Cluster Management
+Red Hat OpenShift GitOps
+Operator
+openshift-operators
+OpenShift GitOps
+Node Feature Discovery
+Operator
+openshift-nfd
+Manages the detection and labeling of hardware features and configuration (for example Intel SGX)
+Intel Device Plugins Operator
+Operator
+openshift-operators
+Advertises Intel specific hardware resources to the kubelet
+Red Hat OpenShift Data Foundation
+Operator
+openshift-storage
+Cloud Native storage solution
+The Intel SGX protected application in Multicloud GitOps pattern also includes the Red Hat Advanced Cluster Management (RHACM) supporting operator that is installed by OpenShift GitOps using Argo CD.
+Intel SGX protected application in Multicloud GitOps pattern with OpenShift clusters sizes The datacenter hub OpenShift cluster needs to be a bit bigger than the Factory/Edge clusters because this is where the developers will be running pipelines to build and deploy the Intel SGX protected application in Multicloud GitOps pattern on the cluster. The above cluster sizing is close to a minimum size for a Datacenter HUB cluster. In the next few sections we take some snapshots of the cluster utilization while the Intel SGX protected application in Multicloud GitOps pattern is running. Keep in mind that resources will have to be added as more developers are working building their applications.
+The recommended clusters sizes for datacenter hub and for managed datacenter are the same in this case:
+Node type Number of nodes CPU Memory Storage Control Planes
+3
+2x 5th Generation Intel Xeon Gold 6526Y (16 cores at 2.8 GHz base with Intel SGX) or better
+128 GB (8 x 16 GB DDR5 4800) or more
+NVME SSD 3TB or more
+Workers
+3
+2x 5th Generation Intel Xeon Gold 6538Y+ (32 cores at 2.2 GHz base with Intel SGX) or better
+256 GB (16 x 16 GB) or 512 GB (16 x 32GB) DDR5-4800
+NVME SSD 3TB or more
+You might want to add resources when more developers are working on building their applications.
+The pattern was tested in the on-premises environment with following hardware configuration (per cluster):
+Node type Number of nodes CPU Memory Storage Control Planes + Workers
+3 + 3
+2x 5th Generation Intel Xeon Platinum 8568Y+ (48 cores at 2.3 GHz base with Intel SGX)
+512 GB (16x32GB DDR5 5600)
+4x 3.84TB U.2 NVMe PCIe Gen4
+`,url:"https://validatedpatterns.io/patterns/multicloud-gitops-sgx-hello-world/mcg-sgx-hello-world-cluster-sizing/",breadcrumb:"/patterns/multicloud-gitops-sgx-hello-world/mcg-sgx-hello-world-cluster-sizing/"},"https://validatedpatterns.io/patterns/multicloud-gitops-sgx/mcg-sgx-cluster-sizing/":{title:"Cluster sizing",tags:[],content:` About OpenShift cluster sizing for the Intel SGX protected Vault for Multicloud GitOps pattern The minimum requirements for an OpenShift Container Platform cluster depend on your installation platform, for example:
+For AWS, see Installing OpenShift Container Platform on AWS.
+For bare-metal, see Installing OpenShift Container Platform on bare metal.
+To understand cluster sizing requirements for the Intel SGX protected Vault for Multicloud GitOps pattern, consider the following components that the Intel SGX protected Vault for Multicloud GitOps pattern deploys on the datacenter or the hub OpenShift cluster:
+Name Kind Namespace Description multicloud-gitops-sgx-hub
+Application
+multicloud-gitops-sgx-hub
+Hub GitOps management
+Red Hat Advanced Cluster Management
+Operator
+open-cluster-management
+Advance Cluster Management
+Red Hat OpenShift GitOps
+Operator
+openshift-operators
+OpenShift GitOps
+Node Feature Discovery
+Operator
+openshift-nfd
+Manages the detection and labeling of hardware features and configuration (for example Intel SGX)
+Intel Device Plugins
+Operator
+openshift-operators
+Collection of plugins, Intel Software Guard Extensions Device Plugin is used in this pattern
+Red Hat OpenShift Data Foundation
+Operator
+openshift-storage
+Cloud Native storage solution
+Intel SGX protected Vault for Multicloud GitOps pattern with OpenShift clusters sizes The datacenter hub OpenShift cluster needs to be a bit bigger than the Factory/Edge clusters because this is where the developers will be running pipelines to build and deploy the Intel SGX protected Vault for Multicloud GitOps pattern on the cluster. The above cluster sizing is close to a minimum size for a Datacenter HUB cluster. In the next few sections we take some snapshots of the cluster utilization while the Intel SGX protected Vault for Multicloud GitOps pattern is running. Keep in mind that resources will have to be added as more developers are working building their applications.
+The recommended clusters sizes for datacenter hub and for managed datacenter are the same in this case:
+Node type Number of nodes CPU Memory Storage Control Planes
+3
+2x 5th Generation Intel Xeon Gold 6526Y (16 cores at 2.8 GHz base with Intel SGX) or better
+128 GB (8 x 16 GB DDR5 4800) or more
+NVME SSD 3TB or more
+Workers
+3
+2x 5th Generation Intel Xeon Gold 6538Y+ (32 cores at 2.2 GHz base with Intel SGX) or better
+256 GB (16 x 16 GB) or 512 GB (16 x 32GB) DDR5-4800
+NVME SSD 3TB or more
+You might want to add resources when more developers are working on building their applications.
+The pattern was tested in the on-premises environment with following hardware configuration (per cluster):
+Node type Number of nodes CPU Memory Storage Control Planes + Workers
+3 + 3
+2x 5th Generation Intel Xeon Platinum 8568Y+ (48 cores at 2.3 GHz base with Intel SGX)
+512 GB (16x32GB DDR5 5600)
+4x 3.84TB U.2 NVMe PCIe Gen4
+`,url:"https://validatedpatterns.io/patterns/multicloud-gitops-sgx/mcg-sgx-cluster-sizing/",breadcrumb:"/patterns/multicloud-gitops-sgx/mcg-sgx-cluster-sizing/"},"https://validatedpatterns.io/patterns/multicloud-gitops/mcg-cluster-sizing/":{title:"Cluster sizing",tags:[],content:` About OpenShift cluster sizing for the Multicloud GitOps Pattern The minimum requirements for an OpenShift Container Platform cluster depend on your installation platform, for example:
+For AWS, see Installing OpenShift Container Platform on AWS.
+For bare-metal, see Installing OpenShift Container Platform on bare metal.
+To understand cluster sizing requirements for the Multicloud GitOps pattern, consider the following components that the Multicloud GitOps pattern deploys on the datacenter or the hub OpenShift cluster:
+Name Kind Namespace Description multicloud-gitops-hub
+Application
+multicloud-gitops-hub
+Hub GitOps management
+Red Hat Advanced Cluster Management
+Operator
+open-cluster-management
+Advance Cluster Management
+Red Hat OpenShift GitOps
+Operator
+openshift-operators
+OpenShift GitOps
+The Multicloud GitOps pattern also includes the Red Hat Advanced Cluster Management (RHACM) supporting operator that is installed by OpenShift GitOps using Argo CD.
+Multicloud GitOps pattern with OpenShift datacenter hub cluster size The Multicloud GitOps pattern has been tested with a defined set of specifically tested configurations that represent the most common combinations that Red Hat OpenShift Container Platform customers are using or deploying for the x86_64 architecture.
+The datacenter hub OpenShift cluster uses the following the AWS deployment configuration:
+Node Type Number of nodes Cloud Provider Instance Type Control Plane
+4
+Amazon Web Services
+m5.xlarge
+Worker
+3
+Amazon Web Services
+m5.xlarge
+The datacenter hub OpenShift cluster needs to be a bit bigger than the Factory/Edge clusters because this is where the developers will be running pipelines to build and deploy the Multicloud GitOps pattern on the cluster. The above cluster sizing is close to a minimum size for a Datacenter HUB cluster. In the next few sections we take some snapshots of the cluster utilization while the Multicloud GitOps pattern is running. Keep in mind that resources will have to be added as more developers are working building their applications.
+Multicloud GitOps pattern with OpenShift managed datacenter cluster size The standard datacenter deployment of an OpenShift cluster is 3 control plane nodes and 3 or more worker nodes.
+Node Type Number of nodes Cloud Provider Instance Type Control Plane/Worker
+3
+Google Cloud
+n1-standard-8
+Control Plane/Worker
+3
+Amazon Cloud Services
+m5.2xlarge
+Control Plane/Worker
+3
+Microsoft Azure
+Standard_D8s_v3
+`,url:"https://validatedpatterns.io/patterns/multicloud-gitops/mcg-cluster-sizing/",breadcrumb:"/patterns/multicloud-gitops/mcg-cluster-sizing/"},"https://validatedpatterns.io/patterns/ansible-edge-gitops-kasten/cluster-sizing/":{title:"Cluster Sizing",tags:[],content:`OpenShift Cluster Sizing for the Ansible Edge GitOps Pattern Tested Platforms The Ansible Edge GitOps pattern has been tested on AWS:
+Certified Cloud Providers 4.9 4.10 Amazon Web Services Tested The pattern is adaptable to running on bare metal/on-prem clusters but has not yet been tested there.
+General OpenShift Minimum Requirements OpenShift 4 has the following minimum requirements for sizing of nodes:
+Minimum 4 vCPU (additional are strongly recommended). Minimum 16 GB RAM (additional memory is strongly recommended, especially if etcd is colocated on Control Planes). Minimum 40 GB hard disk space for the file system containing /var/. Minimum 1 GB hard disk space for the file system containing /usr/local/bin/. There is one application that comprises the Ansible Edge GitOps pattern. In addition, the Ansible Edge GitOps pattern also includes the Advanced Cluster Management (ACM) supporting operator that is installed by OpenShift GitOps using ArgoCD.
+Ansible Edge GitOps Pattern Components Here&rsquo;s an inventory of what gets deployed by the Ansible Edge GitOps pattern on the Datacenter/Hub OpenShift cluster:
+Name Kind Namespace Description Ansible Edge GitOps-hub Application Ansible Edge GitOps-hub Hub GitOps management Red Hat OpenShift GitOps Operator openshift-operators OpenShift GitOps Red Hat Ansible Automation Platform Operator ansible-automation-platform Ansible Automation Red Hat OpenShift Data Foundations Operator openshift-storage OpenShift Storage solution Red Hat OpenShift Virtualization Operator openshift-cnv Virtualization software to run VMs Edge GitOps VMs VMs edge-gitops-vms Simulated Edge environment with VMs to manage Hashicorp Vault Operator vault Secrets Storage External Secrets Operator (ESO) Operator golang-external-secrets Abstraction for secrets storage Veeam Kasten Operator kasten-io Kubernetes Data Protection Ansible Edge GitOps Pattern OpenShift Datacenter HUB Cluster Size The Ansible Edge GitOps pattern has been tested with a defined set of specifically tested configurations that represent the most common combinations that Red Hat OpenShift Container Platform (OCP) customers are using or deploying for the x86_64 architecture.
+The Hub OpenShift Cluster is made up of the the following on the AWS deployment tested:
+Node Type Number of nodes Cloud Provider Instance Type Control Plane 3 Amazon Web Services m5.xlarge Worker 3 Amazon Web Services m5.4xlarge Worker 1 Amazon Web Services c5n.metal The metal node is added to the cluster by the installation process after initial provisioning. The pattern on the hub requires OpenShift Data Fabric to support Virtual Machine storage and is a minimum size for a Hub cluster. In the next few sections we take some snapshots of the cluster utilization while the Ansible Edge GitOps pattern is running. Keep in mind that resources will have to be added as more developers are working building their applications.
+Datacenter Cluster utilization Below is a snapshot of the OpenShift cluster utilization while running the Ansible Edge GitOps pattern:
+CPU CPU% Memory Memory% 321m 0% 12511Mi 6% 736m 21% 7533Mi 51% 673m 4% 9298Mi 14% 920m 26% 8635Mi 59% 673m 4% 9258Mi 14% 921m 26% 9407Mi 65% 395m 2% 5149Mi 8% AWS Instance Types The Ansible Edge GitOps pattern was tested with the highlighted AWS instances in bold. The OpenShift installer will let you know if the instance type meets the minimum requirements for a cluster.
+The message that the openshift installer will give you will be similar to this message
+INFO Credentials loaded from default AWS environment variables FATAL failed to fetch Metadata: failed to load asset &#34;Install Config&#34;: [controlPlane.platform.aws.type: Invalid value: &#34;m4.large&#34;: instance type does not meet minimum resource requirements of 4 vCPUs, controlPlane.platform.aws.type: Invalid value: &#34;m4.large&#34;: instance type does not meet minimum resource requirements of 16384 MiB Memory] Below you can find a list of the AWS instance types that can be used to deploy the Ansible Edge GitOps pattern.
+Instance type Default vCPUs Memory (GiB) Datacenter Factory/Edge 3x3 OCP Cluster 3 Node OCP Cluster m4.xlarge 4 16 N N m4.2xlarge 8 32 Y Y m4.4xlarge 16 64 Y Y m4.10xlarge 40 160 Y Y m4.16xlarge 64 256 Y Y m5.xlarge 4 16 Y N m5.2xlarge 8 32 Y Y m5.4xlarge 16 64 Y Y m5.8xlarge 32 128 Y Y m5.12xlarge 48 192 Y Y m5.16xlarge 64 256 Y Y m5.24xlarge 96 384 Y Y The OpenShift cluster is made of 3 Control Plane nodes and 4 Workers for the Hub cluster; 3 workers are standard compute nodes and one is c5n.metal. For the node sizes we used the m5.4xlarge on AWS and this instance type met the minimum requirements to deploy the Ansible Edge GitOps pattern successfully on the Hub cluster.
+This pattern is currently only usable on AWS because of the integration of OpenShift Virtualization; it would be straightforward to adapt this pattern also to run on bare metal/on-prem clusters. If and when other public cloud providers support metal node provisioning in OpenShift Virtualization, we will document that here.
+`,url:"https://validatedpatterns.io/patterns/ansible-edge-gitops-kasten/cluster-sizing/",breadcrumb:"/patterns/ansible-edge-gitops-kasten/cluster-sizing/"},"https://validatedpatterns.io/patterns/ansible-edge-gitops/cluster-sizing/":{title:"Cluster Sizing",tags:[],content:`OpenShift Cluster Sizing for the Ansible Edge GitOps Pattern Tested Platforms The Ansible Edge GitOps pattern has been tested on AWS:
+Certified Cloud Providers 4.9 4.10 Amazon Web Services Tested The pattern is adaptable to running on bare metal/on-prem clusters but has not yet been tested there.
+General OpenShift Minimum Requirements OpenShift 4 has the following minimum requirements for sizing of nodes:
+Minimum 4 vCPU (additional are strongly recommended). Minimum 16 GB RAM (additional memory is strongly recommended, especially if etcd is colocated on Control Planes). Minimum 40 GB hard disk space for the file system containing /var/. Minimum 1 GB hard disk space for the file system containing /usr/local/bin/. There is one application that comprises the Ansible Edge GitOps pattern. In addition, the Ansible Edge GitOps pattern also includes the Advanced Cluster Management (ACM) supporting operator that is installed by OpenShift GitOps using ArgoCD.
+Ansible Edge GitOps Pattern Components Here&rsquo;s an inventory of what gets deployed by the Ansible Edge GitOps pattern on the Datacenter/Hub OpenShift cluster:
+Name Kind Namespace Description Ansible Edge GitOps-hub Application Ansible Edge GitOps-hub Hub GitOps management Red Hat OpenShift GitOps Operator openshift-operators OpenShift GitOps Red Hat Ansible Automation Platform Operator ansible-automation-platform Ansible Automation Red Hat OpenShift Data Foundations Operator openshift-storage OpenShift Storage solution Red Hat OpenShift Virtualization Operator openshift-cnv Virtualization software to run VMs Edge GitOps VMs VMs edge-gitops-vms Simulated Edge environment with VMs to manage Hashicorp Vault Operator vault Secrets Storage External Secrets Operator (ESO) Operator golang-external-secrets Abstraction for secrets storage Ansible Edge GitOps Pattern OpenShift Datacenter HUB Cluster Size The Ansible Edge GitOps pattern has been tested with a defined set of specifically tested configurations that represent the most common combinations that Red Hat OpenShift Container Platform (OCP) customers are using or deploying for the x86_64 architecture.
+The Hub OpenShift Cluster is made up of the the following on the AWS deployment tested:
+Node Type Number of nodes Cloud Provider Instance Type Control Plane 3 Amazon Web Services m5.xlarge Worker 3 Amazon Web Services m5.4xlarge Worker 1 Amazon Web Services c5n.metal The metal node is added to the cluster by the installation process after initial provisioning. The pattern on the hub requires OpenShift Data Fabric to support Virtual Machine storage and is a minimum size for a Hub cluster. In the next few sections we take some snapshots of the cluster utilization while the Ansible Edge GitOps pattern is running. Keep in mind that resources will have to be added as more developers are working building their applications.
+Datacenter Cluster utilization Below is a snapshot of the OpenShift cluster utilization while running the Ansible Edge GitOps pattern:
+CPU CPU% Memory Memory% 321m 0% 12511Mi 6% 736m 21% 7533Mi 51% 673m 4% 9298Mi 14% 920m 26% 8635Mi 59% 673m 4% 9258Mi 14% 921m 26% 9407Mi 65% 395m 2% 5149Mi 8% AWS Instance Types The Ansible Edge GitOps pattern was tested with the highlighted AWS instances in bold. The OpenShift installer will let you know if the instance type meets the minimum requirements for a cluster.
+The message that the openshift installer will give you will be similar to this message
+INFO Credentials loaded from default AWS environment variables FATAL failed to fetch Metadata: failed to load asset &#34;Install Config&#34;: [controlPlane.platform.aws.type: Invalid value: &#34;m4.large&#34;: instance type does not meet minimum resource requirements of 4 vCPUs, controlPlane.platform.aws.type: Invalid value: &#34;m4.large&#34;: instance type does not meet minimum resource requirements of 16384 MiB Memory] Below you can find a list of the AWS instance types that can be used to deploy the Ansible Edge GitOps pattern.
+Instance type Default vCPUs Memory (GiB) Datacenter Factory/Edge 3x3 OCP Cluster 3 Node OCP Cluster m4.xlarge 4 16 N N m4.2xlarge 8 32 Y Y m4.4xlarge 16 64 Y Y m4.10xlarge 40 160 Y Y m4.16xlarge 64 256 Y Y m5.xlarge 4 16 Y N m5.2xlarge 8 32 Y Y m5.4xlarge 16 64 Y Y m5.8xlarge 32 128 Y Y m5.12xlarge 48 192 Y Y m5.16xlarge 64 256 Y Y m5.24xlarge 96 384 Y Y The OpenShift cluster is made of 3 Control Plane nodes and 4 Workers for the Hub cluster; 3 workers are standard compute nodes and one is c5n.metal. For the node sizes we used the m5.4xlarge on AWS and this instance type met the minimum requirements to deploy the Ansible Edge GitOps pattern successfully on the Hub cluster.
+This pattern is currently only usable on AWS because of the integration of OpenShift Virtualization; it would be straightforward to adapt this pattern also to run on bare metal/on-prem clusters. If and when other public cloud providers support metal node provisioning in OpenShift Virtualization, we will document that here.
+`,url:"https://validatedpatterns.io/patterns/ansible-edge-gitops/cluster-sizing/",breadcrumb:"/patterns/ansible-edge-gitops/cluster-sizing/"},"https://validatedpatterns.io/patterns/multicloud-gitops-portworx/cluster-sizing/":{title:"Cluster Sizing",tags:[],content:`About OpenShift cluster sizing for the Multicloud GitOps Pattern Support matrix for Multicloud GitOps pattern The Multicloud GitOps pattern has been tested in the following Certified Cloud Providers.
+Certified Cloud Providers 4.8 4.9 4.10 Amazon Web Services :heavy_check_mark: Microsoft Azure :heavy_check_mark: Google Cloud Platform :heavy_check_mark: Minimum requirements for OpenShift Container Platform OpenShift 4 has the following minimum requirements for sizing of nodes:
+Minimum 4 vCPU** (additional are strongly recommended) Minimum 16 GB RAM** (additional memory is strongly recommended, especially if etcd is colocated on Control Planes) Minimum 40 GB hard disk space for the file system containing /var/ Minimum 1 GB hard disk space for the file system containing /usr/local/bin/ There is one application that comprises the Medical Diagnosis pattern. In addition, the Multicloud GitOps pattern also includes the Red Hat Advanced Cluster Management (RHACM) supporting operator that is installed by OpenShift GitOps using ArgoCD.
+Understanding Multicloud GitOps pattern components Here&rsquo;s an inventory of what gets deployed by the Multicloud GitOps pattern on the Datacenter/Hub OpenShift cluster:
+Name Kind Namespace Description multicloud-gitops-hub Application multicloud-gitops-hub Hub GitOps management Red Hat Advanced Cluster Management Operator open-cluster-management Advance Cluster Management Red Hat OpenShift GitOps Operator openshift-operators OpenShift GitOps Multicloud GitOps pattern with OpenShift datacenter hub cluster size The Multicloud GitOps pattern has been tested with a defined set of specifically tested configurations that represent the most common combinations that Red Hat OpenShift Container Platform (OCP) customers are using or deploying for the x86_64 architecture.
+The datacenter hub OpenShift cluster is made up of the the following on the AWS deployment tested:
+Node Type Number of nodes Cloud Provider Instance Type Control Plane 4 Amazon Web Services m5.xlarge Worker 3 Amazon Web Services m5.xlarge The datacenter hub OpenShift cluster needs to be a bit bigger than the Factory/Edge clusters because this is where the developers will be running pipelines to build and deploy the Multicloud GitOps pattern on the cluster. The above cluster sizing is close to a minimum size for a Datacenter HUB cluster. In the next few sections we take some snapshots of the cluster utilization while the Multicloud GitOps pattern is running. Keep in mind that resources will have to be added as more developers are working building their applications.
+Datacenter cluster utilization Below is a snapshot of the OpenShift cluster utilization while running the Multicloud GitOps pattern:
+CPU Memory File System Network Pod Count Multicloud GitOps pattern with OpenShift managed datacenter cluster size The OpenShift cluster is a standard datacenter deployment of 3 control plane nodes and 3 or more worker nodes.
+Node Type Number of nodes Cloud Provider Instance Type Control Plane/Worker 3 Google Cloud n1-standard-8 Control Plane/Worker 3 Amazon Cloud Services m5.2xlarge Control Plane/Worker 3 Microsoft Azure Standard_D8s_v3 Managed Datacenter Cluster Utilization GCP
+This is a snapshot of a Google Cloud managed data center cluster running the production Multicloud GitOps pattern.
+CPU Memory File System Network Pod Count AWS
+This is a snapshot of a Amazon Web Services managed data center cluster running the production Multicloud GitOps pattern.
+CPU Memory File System Network Pod Count Azure
+This is a snapshot of an Azure managed data center cluster running the production Multicloud GitOps pattern.
+CPU Memory File System Network Pod Count AWS Instance Types The Multicloud GitOps pattern was tested with the highlighted AWS instances in bold. The OpenShift installer will let you know if the instance type meets the minimum requirements for a cluster.
+The message that the openshift installer will give you will be similar to this message
+INFO Credentials loaded from default AWS environment variables FATAL failed to fetch Metadata: failed to load asset &#34;Install Config&#34;: [controlPlane.platform.aws.type: Invalid value: &#34;m4.large&#34;: instance type does not meet minimum resource requirements of 4 vCPUs, controlPlane.platform.aws.type: Invalid value: &#34;m4.large&#34;: instance type does not meet minimum resource requirements of 16384 MiB Memory] Below you can find a list of the AWS instance types that can be used to deploy the Multicloud GitOps pattern.
+Instance type Default vCPUs Memory (GiB) Datacenter Factory/Edge 3x3 OCP Cluster 3 Node OCP Cluster m4.xlarge 4 16 N N m4.2xlarge 8 32 Y Y m4.4xlarge 16 64 Y Y m4.10xlarge 40 160 Y Y m4.16xlarge 64 256 Y Y m5.xlarge 4 16 Y N m5.2xlarge 8 32 Y Y m5.4xlarge 16 64 Y Y m5.8xlarge 32 128 Y Y m5.12xlarge 48 192 Y Y m5.16xlarge 64 256 Y Y m5.24xlarge 96 384 Y Y The OpenShift cluster is made of 4 Control Plane nodes and 3 Workers for the Datacenter and the Edge/managed data center cluster are made of 3 Control Plane and 3 Worker nodes. For the node sizes we used the m5.xlarge on AWS and this instance type met the minimum requirements to deploy the Multicloud GitOps pattern successfully on the Datacenter hub. On the managed data center cluster we used the m5.xlarge since the minimum cluster was comprised of 3 nodes. .
+To understand better what types of nodes you can use on other Cloud Providers we provide some of the details below.
+Azure Instance Types The Multicloud GitOps pattern was also deployed on Azure using the Standard_D8s_v3 VM size. Below is a table of different VM sizes available for Azure. Keep in mind that due to limited access to Azure we only used the Standard_D8s_v3 VM size.
+The OpenShift cluster is made of 3 Control Plane nodes and 3 Workers for the Datacenter cluster.
+The OpenShift cluster is made of 3 Control Plane nodes and 3 or more workers for each of the managed data center clusters.
+Type Sizes Description General purpose B, Dsv3, Dv3, Dasv4, Dav4, DSv2, Dv2, Av2, DC, DCv2, Dv4, Dsv4, Ddv4, Ddsv4 Balanced CPU-to-memory ratio. Ideal for testing and development, small to medium databases, and low to medium traffic web servers. Compute optimized F, Fs, Fsv2, FX High CPU-to-memory ratio. Good for medium traffic web servers, network appliances, batch processes, and application servers. Memory optimized Esv3, Ev3, Easv4, Eav4, Ev4, Esv4, Edv4, Edsv4, Mv2, M, DSv2, Dv2 High memory-to-CPU ratio. Great for relational database servers, medium to large caches, and in-memory analytics. Storage optimized Lsv2 High disk throughput and IO ideal for Big Data, SQL, NoSQL databases, data warehousing and large transactional databases. GPU NC, NCv2, NCv3, NCasT4_v3, ND, NDv2, NV, NVv3, NVv4 Specialized virtual machines targeted for heavy graphic rendering and video editing, as well as model training and inferencing (ND) with deep learning. Available with single or multiple GPUs. High performance compute HB, HBv2, HBv3, HC, H Our fastest and most powerful CPU virtual machines with optional high-throughput network interfaces (RDMA). For more information please refer to the Azure VM Size Page.
+Google Cloud (GCP) Instance Types The Multicloud GitOps pattern was also deployed on GCP using the n1-standard-8 VM size. Below is a table of different VM sizes available for GCP. Keep in mind that due to limited access to GCP we only used the n1-standard-8 VM size.
+The OpenShift cluster is made of 3 Control Plane and 3 Workers for the Datacenter cluster.
+The OpenShift cluster is made of 3 Nodes combining Control Plane/Workers for the Edge/managed data center cluster.
+The following table provides VM recommendations for different workloads.
+| General purpose | Workload optimized
+Cost-optimized Balanced Scale-out optimized Memory-optimized Compute-optimized Accelerator-optimized E2 N2, N2D, N1 T2D M2, M1 C2 A2 Day-to-day computing at a lower cost Balanced price/performance across a wide range of VM shapes Best performance/cost for scale-out workloads Ultra high-memory workloads Ultra high performance for compute-intensive workloads Optimized for high performance computing workloads For more information please refer to the GCP VM Size Page.
+`,url:"https://validatedpatterns.io/patterns/multicloud-gitops-portworx/cluster-sizing/",breadcrumb:"/patterns/multicloud-gitops-portworx/cluster-sizing/"},"https://validatedpatterns.io/patterns/retail/components/":{title:"Components",tags:[],content:`Component Details The Quarkus Coffeeshop Store Chart This chart is responsible for deploying the applications, services and routes for the Quarkus Coffeeshop demo. It models a set of microservices that would make sense for a coffeeshop retail operation. The detail of what the microservices do is here.
+quarkuscoffeeshop-web Serves as the &ldquo;front end&rdquo; for ordering food and drinks.
+quarkuscoffeeshop-counter The counter service receives the orders, persists them in the database, and notifies when they are ready.
+quarkuscoffeeshop-barista The barista service is responsible for preparing items from the &ldquo;drink&rdquo; side of the menu.
+quarkuscoffeeshop-kitchen The kitchen service is responsible for preparing items from the &ldquo;food&rdquo; side of the menu.
+quarkuscoffeeshop-customerloyalty The customerloyalty service is responsible for generating customer loyalty events, when a customer enters the &ldquo;rewards&rdquo; email. This data is not persisted or tracked anywhere.
+quarkuscoffeeshop-inventory The inventory service is responsible for tracking food and drink inventory.
+quarkuscoffeeshop-customermocker The customermocker can be used to generate test traffic.
+quarkuscoffeeshop-majestic-monolith The &ldquo;majestic monolith&rdquo; builds all the apps into a single bundle, to simplify the process of deploying this app on single node systems.
+All the components look like this in ArgoCD when deployed:
+The chart is designed such that the same chart can be deployed in the hub cluster as the &ldquo;production&rdquo; store, the &ldquo;demo&rdquo; or TEST store, and on a remote cluster.
+The Quarkus Coffeeshop Database Chart This installs a database instance suitable for use in the Retail pattern. It uses the Crunchy PostgreSQL Operator to provide PostgreSQL services, which includes high availability and backup services by default, and other features available.
+Like the store chart, the Database chart can be deployed in the same different scenarios.
+In ArgoCD, it looks like this:
+The Quarkus Coffeeshop Kafka Chart This chart installs Kafka for use in the Retail pattern. It uses the Red Hat AMQ Streams operator.
+The Quarkus Coffeeshop Pipelines Chart The pipelines chart defines build pipelines using the Red Hat OpenShift Pipelines Operator (tektoncd). Pipelines are provided for all of the application images that ship with the pattern; the pipelines all build the app from source, deploy them to the &ldquo;demo&rdquo; namespace, and push them to the configured image registry.
+Like the store and database charts, the kafka chart supports all three modes of deployment.
+The Quarkus Coffeeshop Landing Page Chart The Landing Page chart builds the page that presents the links for the demos in the pattern.
+`,url:"https://validatedpatterns.io/patterns/retail/components/",breadcrumb:"/patterns/retail/components/"},"https://validatedpatterns.io/patterns/multicloud-gitops-sgx-hello-world/mcg-sgx-hello-world-demo-script/":{title:"Demo Script",tags:[],content:` Introduction The multicloud gitops pattern is designed to be an entrypoint into the Validated Patterns framework. Demo, accessible within the pattern, contains two applications config-demo and hello-world to show the basic configuration and execution examples. For more information on Validated Patterns visit our documentation site.
+Objectives In this demo you will complete the following:
+Prepare your local workstation
+Deploy the pattern
+Extend the pattern with a small tweak
+Getting Started Make sure you have met all the installation prerequisites
+Follow the Getting Started Guide to ensure that you have met all of the prerequisites
+This demo begins after ./pattern.sh make install has been executed
+Demo Now that we have deployed the pattern onto our cluster, with origin pointing to your fork and using my-branch as the name of the used branch, we can begin to discover what has happened. You should be able to click on the nine-box and see the following entries:
+If you now click on the &#34;Hub ArgoCD&#34; menu entry you will be taken to the ArgoCD instance with all the applications.
+Secrets loading By default in the MultiCloud GitOps pattern the secrets get loaded automatically via an out of band process inside the vault running in the OCP cluster. This means that running ./pattern.sh make install will also call the load-secrets makefile target. This load-secrets target will look for a yaml file describing the secrets to be loaded into vault and in case it cannot find one it will use the values-secret.yaml.template file in the git repo to try and generate random secrets.
+Let’s copy the template to our home folder and reload the secrets:
+cp ./values-secret.yaml.template ~/values-secret-multicloud-gitops.yaml ./pattern.sh make load-secrets At this point if the config-demo application was not green already it should become green in the ArgoCD user interface.
+Verify the test web pages If you now click on the Routes in the Networking menu entry you will see the following network routes:
+Clicking on the hello-world application should show a small demo app that prints &#34;Hello World!&#34;:
+Once the secrets are loaded correctly inside the vault, clicking on the config-demo route should display a small application where said secret is shown:
+Make a small change to the test web pages Now we can try and tweak the hello-world application and add the below line in the charts/all/hello-world/templates/hello-world-cm.yaml file:
+diff --git a/charts/all/hello-world/templates/hello-world-cm.yaml b/charts/all/hello-world/templates/hello-world-cm.yaml index e59561ca..bd416bc6 100644 --- a/charts/all/hello-world/templates/hello-world-cm.yaml +++ b/charts/all/hello-world/templates/hello-world-cm.yaml @@ -14,6 +14,7 @@ data: &lt;/head&gt; &lt;body&gt; &lt;h1&gt;Hello World!&lt;/h1&gt; + &lt;h1&gt;This is a patched version via git&lt;/h1&gt; &lt;br/&gt; &lt;h2&gt; Hub Cluster domain is &#39;{{ .Values.global.hubClusterDomain }}&#39; &lt;br&gt; Once we commit the above change via git commit -a -m &#34;test a change&#34; and run git push origin my-branch we will be able to observe argo applying the above change:
+Summary You did it! You have completed the deployment of the MultiCloud GitOps pattern and you made a small local change and applied it via GitOps! Hopefully you are getting ideas of how you can take advantage of our GitOps framework to deploy and manage your applications.
+For more information on Validated Patterns visit our website
+`,url:"https://validatedpatterns.io/patterns/multicloud-gitops-sgx-hello-world/mcg-sgx-hello-world-demo-script/",breadcrumb:"/patterns/multicloud-gitops-sgx-hello-world/mcg-sgx-hello-world-demo-script/"},"https://validatedpatterns.io/contribute/extending-a-pattern/":{title:"Extending an existing pattern",tags:[],content:` Introduction to extending a pattern using a fork Extending an existing pattern usually means adding a new product and/or configuration to the existing pattern. This usually requires four steps:
+Adding any required namespace for the product
+Adding a subscription to install and operator
+Adding one or more ArgoCD applications to manage the post-install configuration of the product
+Adding the Helm chart needed to implement the post-install configuration identified in step 3.
+Sometimes there is no operator in OperatorHub for the product and it requires installing the product using a Helm chart.
+These additions need to be made to the appropriate values-&lt;cluster grouping&gt;.yaml file in the top level pattern directory. If the component is on a hub cluster the file would be values-hub.yaml. If it’s on a production cluster that would be in values-production.yaml. Look at the pattern architecture and decide where you need to add the product.
+In the example below AMQ Streams (Kafka) is chosen as a product to add to a pattern.
+Before starting, fork and clone first Visit the github page for the pattern that you wish to extend. E.g. multicloud-gitops. Select “Fork” in the top right corner.
+On the create a new fork page. You can choose what owner repository you want and the name of the fork. Most times you will fork into your personal repo and leave the name the same. When you have made the appropriate changes press the &#34;Create fork&#34; button.
+You will need to clone from the new fork onto you laptop/desktop so that you can do the extension work effectively. So on the new fork’s main page elect the green “Code” button and copy the git repo’s ssh address.
+In an appropriate directory on your laptop (e.g. ~/git) use git clone on the command line using the ssh address copied above. Then create a branch to extend the pattern. For example if you are extending the multicloud-gitops pattern and adding kafka, you will need to clone your fork of multicloud-gitops and create a branch to add Kafka:
+~/git&gt; git clone git@github.com:&lt;your git account&gt;/multicloud-gitops.git ~/git&gt; cd multicloud-gitops ~/git/multicloud-gitops&gt; git checkout -b add-kafka Adding a namespace The first step is to add a namespace in the values-&lt;cluster group&gt;.yaml. Sometimes a specific namespace is expected in other parts of a products configuration. E.g. Red Hat Advanced Cluster Security expects to use the namespace stackrox. While you might try using a different namespace you may encounter issues.
+In our example we are just going to add the namespace my-kafka.
+--- namespaces: ... # other namespaces above my-kafka - my-kafka Adding a subscription The next step is to add the subscription information for the Kubernetes Operator. Sometimes this subscription needs to be added to a specific namespace, e.g. openshift-operators. Check for any operator namespace requirements. In this example just place it in the newly created my-kafka namespace.
+--- subscriptions: ... # other subscriptions amq-streams: name: amq-streams namespace: my-kafka Adding the ArgoCd application The next step is to add the application information. Sometimes you want to group applications in ArgoCD into a project and you can do this by using an existing project grouping or create a new project group. The example below uses an existing project called my-app.
+--- applications: kafka: name: kafka namespace: my-kafka project: my-app path: charts/all/kafka Adding the Helm Chart The path: tag in the above kafka application tells ArgoCD where to find the Helm Chart needed to deploy this application. Paths are relative the the top level pattern directory and therefore in my example that is ~/git/multicloud-gitops.
+ArgoCD will continuously monitor for changes to artifacts in that location for updates to apply. Each different site type would have its own values- file listing subscriptions and applications.
+Helm Charts The previous steps merely instruct ArgoCD to install the operator for AMQ Streams. No Kafka cluster or topics are created. There is more work to be done.
+You must add a Chart for Kafka:
+A Kafka cluster chart
+A Kafka topic chart.
+Because Kafka (AMQ Streams) is often used to communicate across different clusters in multi-cluster and/or multi-cloud environment you are going to add these to the the all sub dir charts/all/kafka/templates directory. In order to do that we must:
+~/git/multicloud-gitops&gt; mkdir charts/all/kafka ~/git/multicloud-gitops&gt; mkdir charts/all/kafka/templates Helm requires a Chart.yaml file and a values.yaml file in the kafka directory. Edit these files in the kafka directory and add the following:
+--- Chart.yaml: apiVersion: v2 name: kafka-cluster description: A Helm chart for Kubernetes # A chart can be either an &#39;application&#39; or a &#39;library&#39; chart. # # Application charts are a collection of templates that can be packaged into versioned archives # to be deployed. # # Library charts provide useful utilities or functions for the chart developer. They&#39;re included as # a dependency of application charts to inject those utilities and functions into the rendering # pipeline. Library charts do not define any templates and therefore cannot be deployed. type: application # This is the chart version. This version number should be incremented each time you make changes # to the chart and its templates, including the app version. # Versions are expected to follow Semantic Versioning (https://semver.org/) version: 0.1.0 # This is the version number of the application being deployed. This version number should be # incremented each time you make changes to the application. Versions are not expected to # follow Semantic Versioning. They should reflect the version the application is using. # It is recommended to use it with quotes. appVersion: &#34;1.16.0&#34; values.yaml:
+--- global: testlab: namespace: lab-kafka Save the files. Having the global.testlab.namespace defined here allows us to override its chart from here or from values-global.yaml.
+The Kafka cluster Helm chart Now we need a chart to deploy a kafka cluster instance. We will create a file called kafka-cluster.yaml in the charts/all/kafka/templates directory. Using your favorite editor edit the file, copy/paste the code below, and save the file.
+kafka-cluster.yaml:
+--- apiVersion: kafka.strimzi.io/v1beta2 kind: Kafka metadata: name: lab-cluster namespace: {{ .Values.global.testlab.namespace }} # annotations: # argocd.argoproj.io/sync-options: SkipDryRunOnMissingResource=true # # NOTE if needed you can use argocd sync-wave to delay a manifest # argocd.argoproj.io/sync-wave: &#34;3&#34; spec: entityOperator: topicOperator: {} userOperator: {} kafka: config: default.replication.factor: 3 inter.broker.protocol.version: &#39;3.3&#39; min.insync.replicas: 2 offsets.topic.replication.factor: 3 transaction.state.log.min.isr: 2 transaction.state.log.replication.factor: 3 listeners: - name: plain port: 9092 tls: true type: route - name: tls port: 9093 tls: true type: route configuration: bootstrap: host: bootstrap-factory-kafka-cluster.{{ .Values.global.localClusterDomain }} replicas: 3 storage: type: ephemeral version: 3.3.1 zookeeper: replicas: 3 storage: type: ephemeral Topic Helm Chart We also need a chart to deploy a kafka stream. We will create a file called kafka-topic.yaml in the charts/all/kafka/templates directory. Using your favorite editor edit the file, copy/paste the code below, and save the file.
+kafka-topic.yaml:
+--- apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaTopic metadata: name: lab-stream namespace: {{ .Values.global.testlab.namespace }} labels: strimzi.io/cluster: lab-cluster spec: partitions: 1 replicas: 1 config: retention.ms: 604800000 segment.bytes: 1073741824 Add, Commit &amp; Push Steps:
+Use git status to see what’s changed that you need to add to your commit and add them using git add
+Commit the changes to the branch
+Push the branch to your fork.
+~/git/multicloud-gitops&gt; git status ~/git/multicloud-gitops&gt; git add &lt;the assets created/changed&gt; ~/git/multicloud-gitops&gt; git commit -m “Added Kafka using AMQ Stream operator and Helm charts” ~/git/multicloud-gitops&gt; git push origin multicloud-gitops Watch OpenShift GitOps hub cluster UI and see Kafka get deployed Let’s check the OpenShift console. This can take a bit of time for ArgoCD to pick it up and deploy the assets.
+Select installed operators. Is AMQ Streams Operator deployed?
+Select the Red Hat Integration - AMQ Streams operator.
+Select Kafka tab. Is there a new lab-cluster created?
+Select the Kafka Topic tab. Is there a lab-streams topic created?
+This is a very simple and minimal Kafka set up. It is likely you will need to add more manifests to the Chart but it is a good start.
+`,url:"https://validatedpatterns.io/contribute/extending-a-pattern/",breadcrumb:"/contribute/extending-a-pattern/"},"https://validatedpatterns.io/patterns/multicloud-gitops-amx-rhoai/mcg-amx-rhoai-bert-script/":{title:"Intel AMX Demo",tags:[],content:` Introduction The Intel AMX accelerated Multicloud GitOps pattern with Openshift AI provides developers and data scientists with Red Hat OpenShift AI product that is fully configured and ready to go. It also helps to boost their workloads by integrating AMX, which ensures efficiency and performance optimization for AI workloads.
+AMX demo Using 5th Generation Intel Xeon Scalable Processors the kernel detects Intel® AMX at run-time, there is no need to enable and configure it additionally to improve performance. However, we need Intel optimized tools and frameworks to take advantage of AMX acceleration, such as OpenVINO Toolkit.
+Before proceeding with this demo steps, please make sure you have your pattern deployed with Getting started.
+Verify if the openvino-notebooks-v2022.3-1 build is completed under Builds &gt; Builds. Build might take some time and before it is finished it won’t be accessible from Openshift AI console.
+Open OpenShift AI dashboard and go to Applications &gt; Enabled window.
+Open Jupyter by clicking Launch application.
+Choose OpenVINO™ Toolkit v2022.3 notebook image with X Large container size and start the notebook server. Server launching will take several minutes. Once it is ready, go to access notebook server.
+On the Jupyter Launcher window choose Notebook with Python 3 (ipykernel).
+Download BERT-large example, that uses AMX accelerator, by typing in the opened notebook:
+!wget https://raw.githubusercontent.com/validatedpatterns-sandbox/amx-accelerated-rhoai-multicloud-gitops/main/scripts/BERT.ipynb -O BERT.ipynb On the left-hand side menu the BERT.ipynb script should show up. Open it and run instructions one by one with play button or with Ctr+Enter from keyboard.
+All necessary tools like Model Downloader and Benchmark Python Tool are built in and ready to use.
+Description of BERT.ipynb In case of issues with downloading the script, you can copy the following steps into your notebook and run.
+%env ONEDNN_VERBOSE=1 Download the BERT-Large model compatible with FP32&amp;BF16 precision bert-large-uncased-whole-word-masking-squad-0001:
+!omz_downloader --name bert-large-uncased-whole-word-masking-squad-0001 Go to the directory with downloaded model and run the benchmark tool with parameter infer_precision bf16 to use BF16 precision:
+%cd /opt/app-root/src/intel/bert-large-uncased-whole-word-masking-squad-0001/FP32/ !benchmark_app -m bert-large-uncased-whole-word-masking-squad-0001.xml -infer_precision bf16 In ONEDNN verbose you should see avx_512_core_amx entry, what confirms that AMX instructions are being used.
+Figure 1. BERT inference log `,url:"https://validatedpatterns.io/patterns/multicloud-gitops-amx-rhoai/mcg-amx-rhoai-bert-script/",breadcrumb:"/patterns/multicloud-gitops-amx-rhoai/mcg-amx-rhoai-bert-script/"},"https://validatedpatterns.io/learn/keyconcepts/":{title:"Key concepts",tags:[],content:`Key concepts This section describes a set of key concepts essential for creating validated pattern. This material provides you with foundational knowledge to get familiar with the validated patterns framework. The content offers a clear and structured starting point, helping you understand and effectively apply these concepts in your projects.
+Helm and Kustomize Two options are available that allow you to manage the lifecycle of Kubernetes applications you want to deploy with the validated patterns framework. The tools supported are Kustomize and Helm.
+Kustomize: Kustomize is a configuration management tool used to make declarative changes to application configurations and components and preserve the original base YAML files. Kustomize allows you to manage Kubernetes resource files in a declarative manner, using a set of layered configurations. Kustomize excels at managing predefined configurations, but it requires that all customizations be stored as overlays in Git. This approach can lead to a proliferation of overlay directories, becoming disorganized and complex to manage as the number of developers and components grows, making them increasingly difficult to read.
+Helm: Helm is a package manager for Kubernetes, which simplifies the process of defining, installing, and upgrading complex Kubernetes applications. Instead of ad-hoc patching of YAML files, Helm uses a templating language where variables are defined in the raw YAML and combined with actual values at runtime. This allows for the use of conditionals to adapt configurations to different environments and loops to dynamically create multiple instances consistently, such as generating a list of 12 namespaces. It manages Kubernetes manifests using a packaging format called Charts.
+Helm’s templating capabilities, flexibility in handling variables, and advanced features such as conditionals and loops makes it the preferred mechanism for deploying applications in the validated patterns framework. It streamlines the configuration process, reduces complexity, and enhances maintainability, providing a robust solution for managing Kubernetes deployments.
+Helm in validated patterns Helm is the preferred tool for deploying applications within the validated patterns framework. Helm charts are packages that describe a set of Kubernetes resources ready for deployment, including customizable values for application deployment and functions for distributing charts and updates. A Helm chart consists of files structured to include chart metadata such as name and version, resource definitions, and supporting materials. This structure facilitates clear organization and management of Kubernetes resources.
+A minimal Helm chart includes:
+sample/ ├── Chart (1) ├── templates (2) │ └── example.yaml └── values.yaml (3) 1 The Chart.yaml file contains chart metadata, such as the name and version of the chart. 2 The templates directory contains files that define application resources such as deployments. 3 The values.yaml file contains default values for the chart. ArgoCD and Helm Integration ArgoCD integrates with Helm to provide a powerful GitOps-based deployment mechanism. The validated patterns framework uses ArgoCD and Helm to streamline application deployment by defining applications as Helm charts stored in Git repositories. ArgoCD is the tool of choice to apply the desired state of desired application to the target cluster environment.
+ArgoCD automates the deployment and synchronization of these applications to OpenShift Container Platform clusters, ensuring consistency, reliability, and efficiency in managing Kubernetes applications. This integration supports automated, declarative, and version-controlled deployments, enhancing operational efficiency and maintaining application state across environments. ArgoCD helps implement continuous deployment for cloud-native applications.
+Values Values files are essential for customizing settings in applications, services, or validated patterns, particularly in Kubernetes deployments using Helm charts. These files, written in plain YAML format, provide a structured and flexible approach to set parameters and configurations for deploying validated patterns. The values files contain the variables that drive the configurations of your namespaces, subscriptions, applications, and other resources. The variables defined in your values files are referenced within your Helm chart templates. This ensures consistency and enables dynamic configurations. Combined with the power of the Helm’s templating language you can implement conditionals and loops for adaptable and scalable configurations.
+Key characteristics of values files include:
+Plain YAML Format: The human-readable and easy-to-edit syntax of YAML makes configuration settings accessible and straightforward to manage.
+Hierarchical Nature: Values files support a hierarchy of values, allowing logical organization and structuring of configurations, which is especially useful in handling complex deployments. In Helm charts, values files define configuration settings for deploying applications and managing resources within an OpenShift Container Platform cluster. They enable flexible, per-cluster customization while ensuring consistency with the overall validated pattern. This ensures that organizations can achieve efficient, secure, and consistent deployments across multiple OpenShift Container Platform clusters.
+A common practice is to use a base values file, such as values-global.yaml, for global settings, and then have cluster-specific values files for example values-cluster1.yaml, values-cluster2.yaml that override or add to the global settings. This approach allows for comprehensive customization while maintaining a centralized and organized configuration structure, promoting best practices for deployment and resource management.
+For more information, see Exploring values.
+Applications The applications section in the Helm values file plays a crucial role in defining and managing the deployment of various applications within an OpenShift Container Platform cluster. By leveraging Helm charts and adhering to validated patterns, it ensures consistency, best practices, and simplified management, leading to reliable and scalable application deployments.
+The path field in each application entry points in the values file points to the location of the Helm chart and associated configuration files. These charts contain the Kubernetes manifests and configuration necessary to deploy the application. Helm charts are used to package Kubernetes applications and manage their deployment in a consistent and reproducible manner.
+When these applications are deployed, the following Kubernetes resources are typically created:
+Deployments: Define the desired state and replicas for the application’s pods.
+Services: Expose the application’s pods to other services or external traffic.
+ConfigMaps and Secrets: Store configuration data and sensitive information.
+PersistentVolumeClaims (PVCs): Request storage resources for the application.
+Ingress or Routes: Provide external access to the application.
+RBAC (Role-Based Access Control): Define access permissions and roles.
+Red Hat Advanced Cluster Management (RHACM) One of the applications deployed by the Validated Patterns Operator is Red Hat Advanced Cluster Management (RHACM). RHACM is a comprehensive solution designed to manage multiple OpenShift Container Platform clusters, whether that is ten clusters or a thousand clusters and enforce policies across those clusters from a single pane of glass.
+RHACM plays a pivotal role in the validated pattern framework by providing robust capabilities for managing Kubernetes clusters and enforcing policies across heterogeneous environments. RHACM is only installed when a pattern spans multiple clusters. It supports operational efficiency, scalability, compliance, and security, making it an essential tool for organizations looking to manage their Kubernetes infrastructure effectively.
+The Validated Patterns framework uses ACM policies to ensure that applications, targeted for specific clusters, are deployed to the appropriate cluster environments. The single pane of glass allows you to see information about your clusters. RHACM supports multiple cloud providers out of the box and it gives you a clear insight into the resources for that cluster using the observability feature.
+ClusterGroups In a validated pattern, a ClusterGroup organizes and manages clusters sharing common configurations, policies, or deployment needs, with the default group initially encompassing all clusters unless assigned elsewhere. Multiple cluster groups within a pattern allow for tailored management, enabling specific configurations and policies based on roles, environments, or locations. This segmentation enhances efficiency, consistency, and simplifies complex environments. In the validated patterns framework, a ClusterGroup is a key entity representing either a single cluster or a collection of clusters with unique configurations, determined by Helm charts and Kubernetes features. Typically, a ClusterGroup serves as the foundation for each pattern, with the primary one named in values-global.yaml, often referred to as hub. Managed ClusterGroups can also be defined, specifying characteristics and policies for additional clusters. Managed cluster groups are sets of clusters, grouped by function, that share a common configuration set. There is no limitation on the number of groups, or the number of clusters within each group.
+When joining a managed cluster to Red Hat Advanced Cluster Management (RHACM) or deploying a new cluster with RHACM, it must be assigned to at least one ClusterGroup. RHACM identifies the managed cluster’s membership in a ClusterGroup and proceeds to set up the cluster, including installing the RHACM agent. Once the setup is complete, RHACM deploys GitOps and supplies it with information about the ClusterGroup. GitOps then retrieves the associated values file and proceeds to deploy the Operators, configurations, and charts accordingly.
+For more information, see ClusterGroup configuration in values files.
+GitOps GitOps is a way to manage cloud-native systems that are powered by Kubernetes. It leverages a policy-as-code approach to define and manage every layer of the modern application stack from infrastructure, networking application code, and the GitOps pipeline itself.
+The key principle of GitOps are:
+Declarative: The methodology requires describing the desired state, achieved through raw manifests, helm charts, kustomize, or other forms of automation.
+Versioned and immutability: Git ensures versioning and immutability, serving as the definitive source of truth. Version control and historical tracking offer insights into changes that impact the clusters.
+Pulled automatically: The GitOps controller pulls the state automatically to prevent any errors introduced by humans, and it also allows the application an opportunity to heal itself.
+Continuously reconciled: The GitOps controller has a reconciliation loop that by default runs every 3 minutes. When the reconciler identifies a diff between git and the cluster, it will reconcile the change onto the cluster during the next synchronization.
+GitOps within the validated pattern framework ensures that infrastructure and application configurations are managed declaratively, consistently, and securely. GitOps ensures consistency across our environments, platforms and applications.
+For more information, see GitOps.
+Namespaces Namespaces in a validated pattern are essential for organizing and managing resources within an OpenShift Container Platform cluster, ensuring security, consistency, and efficient resource allocation. Recommendations for defining namespaces include using consistent naming conventions, ensuring isolation and security through policies and RBAC, setting resource quotas, tailoring configurations to specific environments, and designing namespaces for modularity and reusability across patterns or applications.
+Operators generally create their own namespaces, but you might need to create additional ones. Check if there are expected namespaces with the product before creating new ones.
+For more information, see Understanding Namespace Creation using the Validated Patterns Framework.
+Subscriptions Subscriptions in a validated pattern typically refer to a methodical approach to managing and deploying applications and services within an OpenShift cluster. Subscriptions within a ClusterGroup in validated patterns streamline access management and resource allocation, allowing administrators to efficiently control user and application permissions, allocate resources precisely, and enforce governance policies.
+Subscriptions are defined in the values files and they are OpenShift Operator subscriptions from the Operator Hub. Subscriptions contribute to the creation of a software bill of materials (SBOM), enhancing transparency and security by detailing all intended installations within the ClusterGroup. Managed through the Operator Lifecycle Manager (OLM), these subscriptions ensure continuous operation and upgrades of operators, similar to RPM packages on RHEL, thus maintaining cluster health and security.
+To maximize the benefits of subscriptions, it is crucial to align them with organizational needs, integrate automated monitoring and alerting, and regularly review and update subscription plans.
+Secrets Enterprise applications, especially in multi-cluster and multi-site environments, require robust security measures, including the use of certificates and other secrets to establish trust. Managing these secrets effectively is crucial.
+Ignoring security during the development of distributed enterprise applications can lead to significant technical debt. The DevSecOps model addresses this by emphasizing the need to integrate security early in the development lifecycle, known as &#34;shifting security to the left.&#34;
+In the OpenShift Container Platform, secrets are used to securely store sensitive information like passwords, API keys, and certificates. These secrets are managed using Kubernetes secret objects within validated patterns, ensuring consistent, secure, and compliant deployments. This approach promotes best practices for security and simplifies the management of sensitive data across OpenShift Container Platform Container Platform deployments.
+For more information, see Overview of secrets management.
+Shared values Shared values files are YAML files used in a validated pattern to centralize and manage configuration settings. They define common parameters and settings that can be reused across multiple clusters, applications, and environments. This approach promotes consistency and simplifies configuration management.
+Shared values files are a powerful mechanism in a validated pattern, enabling centralized, consistent, and reusable configuration management across multiple clusters and environments. By defining global settings and leveraging cluster-specific overrides, they ensure that configurations are both standardized and flexible enough to accommodate specific needs of individual clusters.
+Tests Tests within the Validated Pattern Framework are essential components to validate and ensure that the deployed patterns and configurations adhere to operational standards, security protocols, performance expectations, and compliance requirements in Kubernetes and OpenShift Container Platform environments.
+`,url:"https://validatedpatterns.io/learn/keyconcepts/",breadcrumb:"/learn/keyconcepts/"},"https://validatedpatterns.io/patterns/gaudi-rag-chat-qna/gaudi-rag-chat-qna-required-hardware/":{title:"Required Hardware",tags:[],content:` Required Hardware Intel® Gaudi® With the surging demand for the advantages deep learning and generative Al can bring, there’s never been a greater need for improved computing performance, efficiency, usability, and choice.
+Intel® Gaudi® Al accelerators and software are designed to bring a new level of computing advantages and choice to data center training and inference-whether in the cloud or on-premises.
+More information can be found on official Gaudi website.
+Recommended platforms We have deployed and tested this Validated Pattern on two platforms:
+Supermicro AI Training SuperServer SYS-820GH-TNR2
+DELL PowerEdge XE9680 Rack Server
+`,url:"https://validatedpatterns.io/patterns/gaudi-rag-chat-qna/gaudi-rag-chat-qna-required-hardware/",breadcrumb:"/patterns/gaudi-rag-chat-qna/gaudi-rag-chat-qna-required-hardware/"},"https://validatedpatterns.io/patterns/devsecops/production-cluster/":{title:"Secured Production Clusters",tags:[],content:`Having a production cluster join the hub Introduction Production clusters need to be secured and so one part of the deployment is to install the Advanced Cluster Security operator with a secured configuration. This allows ACS central to monitor and report on security issues on the cluster. ACS secured sites report to an ACS Central application that is deployed on the hub.
+Allow ACM to deploy the production application to a subset of secured clusters By default the production applications are deployed on all prod clusters that ACM knows about.
+- name: secured helmOverrides: - name: clusterGroup.isHubCluster value: &#34;false&#34; clusterSelector: matchLabels: clusterGroup: prod matchExpressions: - key: vendor operator: In values: - OpenShift Remember to commit the changes and push to GitHub so that GitOps can see your changes and apply them.
+Deploy a Production (prod) cluster For instructions on how to prepare and import a production (prod) cluster please read the section importing a cluster. Use clusterGroup=prod.
+You are done importing the production cluster That&rsquo;s it! Go to your production OpenShift console and check for the open-cluster-management-agent pod being launched. Be patient, it will take a while for the ACM agent and agent-addons to launch. After that, the operator OpenShift GitOps will run. When it&rsquo;s finished coming up launch the OpenShift GitOps (ArgoCD) console from the top right of the OpenShift console.
+Next up Work your way through the Multicluster DevSecOps GitOps/DevOps demos (TBD)
+`,url:"https://validatedpatterns.io/patterns/devsecops/production-cluster/",breadcrumb:"/patterns/devsecops/production-cluster/"},"https://validatedpatterns.io/patterns/ansible-edge-gitops-kasten/ansible-automation-platform/":{title:"Ansible Automation Platform",tags:[],content:`Ansible Automation Platform How it&rsquo;s installed See the installation details here.
+How to Log In The default login user is admin and the password is generated randomly at install time; you will need the password to login in to the AAP interface. You do not have to log in to the interface - the pattern will configure the AAP instance; the pattern retrieves the password using the same technique as the ansible_get_credentials.sh script described below. If you want to inspect the AAP instance, or change any aspects of its configuration, there are two ways to login and look at it. Both mechanisms are equivalent; you get the same password to the same instance using either technique.
+Via the OpenShift Console In the OpenShift console, navigate to Workloads &gt; Secrets and select the &ldquo;ansible-automation-platform&rdquo; project if you want to limit the number of Secrets you can see.
+The Secret you are looking for is in the ansible-automation-platform project and is named controller-admin-password. If you click on it, you can see the Data.password field. It is shown revealed below to show that it is the same as what is shown by the script method of retrieving it below:
+Via ansible_get_credentials.sh With your KUBECONFIG set, you can run ./scripts/ansible-get-credentials.sh from your top-level pattern directory. This will use your OpenShift cluster admin credentials to retrieve the URL for your Ansible Automation Platform instance, as well as the password for its admin user, which is auto-generated by the AAP operator by default. The output of the command looks like this (your password will be different):
+./scripts/ansible_get_credentials.sh [WARNING]: provided hosts list is empty, only localhost is available. Note that the implicit localhost does not match &#39;all&#39; PLAY [Install manifest on AAP controller] ****************************************************************************** TASK [Retrieve API hostname for AAP] *********************************************************************************** ok: [localhost] TASK [Set ansible_host] ************************************************************************************************ ok: [localhost] TASK [Retrieve admin password for AAP] ********************************************************************************* ok: [localhost] TASK [Set admin_password fact] ***************************************************************************************** ok: [localhost] TASK [Report AAP Endpoint] ********************************************************************************************* ok: [localhost] =&gt; { &#34;msg&#34;: &#34;AAP Endpoint: https://controller-ansible-automation-platform.apps.mhjacks-aeg.blueprints.rhecoeng.com&#34; } TASK [Report AAP User] ************************************************************************************************* ok: [localhost] =&gt; { &#34;msg&#34;: &#34;AAP Admin User: admin&#34; } TASK [Report AAP Admin Password] *************************************************************************************** ok: [localhost] =&gt; { &#34;msg&#34;: &#34;AAP Admin Password: CKollUjlir0EfrQuRrKuOJRLSQhi4a9E&#34; } PLAY RECAP ************************************************************************************************************* localhost : ok=7 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 Pattern AAP Configuration Details In this section, we describe the details of the AAP configuration we apply as part of installing the pattern. All of the configuration discussed in this section is applied by the ansible_load_controller.sh script.
+Loading a Manifest After validating that AAP is ready to be configured, the first thing the script does is to install the manifest you specify in the values-secret.yaml file in the files.manifest setting. The value of this setting is expected to be a fully-pathed file that represents a Red Hat Satellite manifest file with a valid entitlement for AAP. The only thing this manifest is used for is entitling AAP.
+Instructions for creating a suitable manifest file can be found here.
+While it is absolutely possible to entitle AAP via a username/password on first login, the automated mechanisms for entitling only support manifests, that is the technique the pattern uses.
+Organizations The pattern installs an Organization called HMI Demo is installed. This makes it a bit easier to separate what the pattern is doing versus the default configuration of AAP. The other resources created in AAP as part of the load process are associated with this Organization.
+Credential Types (and their Credentials) Kubeconfig (Kubeconfig) The Kubeconfig credential is for holding the OpenShift cluster admin kubeconfig file. This is used to query the edge-gitops-vms namespace for running VM instances. Since the kubeconfig is necessary for installing the pattern and must be available when the load script is running, the load script pulls it into an AAP secret and stores it for later use (and calls it Kubeconfig).
+The template for creating the Credential Type was taken from here.
+RHSMcredential (rhsm_credential) This credential is required to register the RHEL VMs and configure them for Kiosk mode. The registration process allows them to install packages from the Red Hat Content Delivery Network.
+Machine (kiosk-private-key) This is a standard AAP Machine type credential. kiosk-private-key is created with the username and private key from your values-secret.yaml file in the kiosk-ssh.username and kiosk-ssh.privatekey fields.
+KioskExtraParams (kiosk_container_extra_params) This CredentialType is considered &ldquo;secret&rdquo; because it includes the admin login password for the Ignition application. This passed to the provisioning playbook(s) as extra_vars.
+Inventory The pattern installs an Inventory (HMI Demo), but no inventory sources. This is due to the way that OpenShift Virtualization provides access to virtual machines. The IP address associated with the SSH service that a given VM is running is associated with the Service object on the VM. This is not the way the Kubernetes inventory plugin expects to work. So to make inventory dynamic, we are instead using a play to discover VMs and add them to inventory &ldquo;on the fly&rdquo;. What is unusual about DNS inside a Kubernetes cluster is that resources outside the namespace must use the cluster FQDN - which is resource-name.resource-namespace.svc.
+It is also possible to define a static inventory - an example of how this would like is preserved in the pattern repository as hosts.
+A standard dynamic inventory script is available here. This will retrieve the object names, but it will not (currently) map the FQDN properly. Because of this limitation, we moved to using the inventory pre-play method.
+Templates (key playbooks in the pattern) Dynamic Provision Kiosk Playbook This combines all three key workflows in this pattern:
+Dynamic inventory (inventory preplay) Kiosk Mode Podman Playbook It is safe to run multiple times on the same system. It is run on a schedule, every 10 minutes, to demonstrate this.
+Kiosk Mode Playbook This playbook runs the kiosk_mode role.
+Podman Playbook This playbook runs the container_lifecycle role with overrides suitable for the Ignition application container.
+Ping Playbook This playbook is for testing basic connectivity - making sure that you can reach the nodes you wish to manage, and that the credentials you have given will work on them. It will not change anything on the VMs - just gather facts from them (which requires elevating to root).
+Schedules Update Project AEG GitOps This job runs every 5 minutes to update the GitOps repository associated with the project. This is necessary when any of the Ansible code (for example, the playbooks or roles associated with the pattern) changes, so that the new code is available to the AAP instance.
+Dynamic Provision Kiosk Playbook This job runs every 10 minutes to provision and configure any kiosks it finds to run the Ignition application in a podman container, and configure firefox in kiosk mode to display that application. The playbook is designed to be idempotent, so it is safe to run multiple times on the same targets; it will not make user-visible changes to those targets unless it must.
+This playbook combines the inventory_preplay and the Provision Kiosk Playbook.
+Execution Environment The pattern includes an execution environment definition that can be found here.
+The execution environment includes some additional collections beyond what is provided in the Default execution environment, including:
+fedora.linux_system_roles containers.podman community.okd The execution environment definition is provided if you want to customize or change it; if so, you should also change the Execution Environment attributes of the Templates (in the load script, those attributes are set by the variables aap_execution_environment and aap_execution_environment_image).
+Roles included in the pattern kiosk_mode This role is responsible does the following:
+RHEL node registration Installation of GUI packages Installation of Firefox Configuration of Firefox kiosk mode container_lifecycle This role is responsible for:
+Downloading and running a podman image on the system (and configure it to auto-update) Setting the container up to run at boot time Passing any other runtime arguments to the container. In this container&rsquo;s case, that includes specifying an admin password override. Extra Playbooks in the Pattern inventory_preplay.yml This playbook is designed to be included in other plays; its purpose is to discover the desired inventory and add those hosts to inventory at runtime. It uses a kubernetes query via the cluster-admin kube config file.
+Provision Kiosk Playbook This does the work of provisioning the kiosk, which configures kiosk mode, and also installs Ignition and configures it to start at boot. It runs the kiosk_mode and container_lifecycle roles.
+Next Steps Help &amp; Feedback Report Bugs `,url:"https://validatedpatterns.io/patterns/ansible-edge-gitops-kasten/ansible-automation-platform/",breadcrumb:"/patterns/ansible-edge-gitops-kasten/ansible-automation-platform/"},"https://validatedpatterns.io/patterns/ansible-edge-gitops/ansible-automation-platform/":{title:"Ansible Automation Platform",tags:[],content:`Ansible Automation Platform How it&rsquo;s installed See the installation details here.
+How to Log In The default login user is admin and the password is generated randomly at install time; you will need the password to login in to the AAP interface. You do not have to log in to the interface - the pattern will configure the AAP instance; the pattern retrieves the password using the same technique as the ansible_get_credentials.sh script described below. If you want to inspect the AAP instance, or change any aspects of its configuration, there are two ways to login and look at it. Both mechanisms are equivalent; you get the same password to the same instance using either technique.
+Via the OpenShift Console In the OpenShift console, navigate to Workloads &gt; Secrets and select the &ldquo;ansible-automation-platform&rdquo; project if you want to limit the number of Secrets you can see.
+The Secret you are looking for is in the ansible-automation-platform project and is named controller-admin-password. If you click on it, you can see the Data.password field. It is shown revealed below to show that it is the same as what is shown by the script method of retrieving it below:
+Via ansible_get_credentials.sh With your KUBECONFIG set, you can run ./scripts/ansible-get-credentials.sh from your top-level pattern directory. This will use your OpenShift cluster admin credentials to retrieve the URL for your Ansible Automation Platform instance, as well as the password for its admin user, which is auto-generated by the AAP operator by default. The output of the command looks like this (your password will be different):
+./scripts/ansible_get_credentials.sh [WARNING]: provided hosts list is empty, only localhost is available. Note that the implicit localhost does not match &#39;all&#39; PLAY [Install manifest on AAP controller] ****************************************************************************** TASK [Retrieve API hostname for AAP] *********************************************************************************** ok: [localhost] TASK [Set ansible_host] ************************************************************************************************ ok: [localhost] TASK [Retrieve admin password for AAP] ********************************************************************************* ok: [localhost] TASK [Set admin_password fact] ***************************************************************************************** ok: [localhost] TASK [Report AAP Endpoint] ********************************************************************************************* ok: [localhost] =&gt; { &#34;msg&#34;: &#34;AAP Endpoint: https://controller-ansible-automation-platform.apps.mhjacks-aeg.blueprints.rhecoeng.com&#34; } TASK [Report AAP User] ************************************************************************************************* ok: [localhost] =&gt; { &#34;msg&#34;: &#34;AAP Admin User: admin&#34; } TASK [Report AAP Admin Password] *************************************************************************************** ok: [localhost] =&gt; { &#34;msg&#34;: &#34;AAP Admin Password: CKollUjlir0EfrQuRrKuOJRLSQhi4a9E&#34; } PLAY RECAP ************************************************************************************************************* localhost : ok=7 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 Pattern AAP Configuration Details In this section, we describe the details of the AAP configuration we apply as part of installing the pattern. All of the configuration discussed in this section is applied by the ansible_load_controller.sh script.
+Loading a Manifest After validating that AAP is ready to be configured, the first thing the script does is to install the manifest you specify in the values-secret.yaml file in the files.manifest setting. The value of this setting is expected to be a fully-pathed file that represents a Red Hat Satellite manifest file with a valid entitlement for AAP. The only thing this manifest is used for is entitling AAP.
+Instructions for creating a suitable manifest file can be found here.
+While it is absolutely possible to entitle AAP via a username/password on first login, the automated mechanisms for entitling only support manifests, that is the technique the pattern uses.
+Organizations The pattern installs an Organization called HMI Demo is installed. This makes it a bit easier to separate what the pattern is doing versus the default configuration of AAP. The other resources created in AAP as part of the load process are associated with this Organization.
+Credential Types (and their Credentials) Kubeconfig (Kubeconfig) The Kubeconfig credential is for holding the OpenShift cluster admin kubeconfig file. This is used to query the edge-gitops-vms namespace for running VM instances. Since the kubeconfig is necessary for installing the pattern and must be available when the load script is running, the load script pulls it into an AAP secret and stores it for later use (and calls it Kubeconfig).
+The template for creating the Credential Type was taken from here.
+RHSMcredential (rhsm_credential) This credential is required to register the RHEL VMs and configure them for Kiosk mode. The registration process allows them to install packages from the Red Hat Content Delivery Network.
+Machine (kiosk-private-key) This is a standard AAP Machine type credential. kiosk-private-key is created with the username and private key from your values-secret.yaml file in the kiosk-ssh.username and kiosk-ssh.privatekey fields.
+KioskExtraParams (kiosk_container_extra_params) This CredentialType is considered &ldquo;secret&rdquo; because it includes the admin login password for the Ignition application. This passed to the provisioning playbook(s) as extra_vars.
+Inventory The pattern installs an Inventory (HMI Demo), but no inventory sources. This is due to the way that OpenShift Virtualization provides access to virtual machines. The IP address associated with the SSH service that a given VM is running is associated with the Service object on the VM. This is not the way the Kubernetes inventory plugin expects to work. So to make inventory dynamic, we are instead using a play to discover VMs and add them to inventory &ldquo;on the fly&rdquo;. What is unusual about DNS inside a Kubernetes cluster is that resources outside the namespace must use the cluster FQDN - which is resource-name.resource-namespace.svc.
+It is also possible to define a static inventory - an example of how this would like is preserved in the pattern repository as hosts.
+A standard dynamic inventory script is available here. This will retrieve the object names, but it will not (currently) map the FQDN properly. Because of this limitation, we moved to using the inventory pre-play method.
+Templates (key playbooks in the pattern) Dynamic Provision Kiosk Playbook This combines all three key workflows in this pattern:
+Dynamic inventory (inventory preplay) Kiosk Mode Podman Playbook It is safe to run multiple times on the same system. It is run on a schedule, every 10 minutes, to demonstrate this.
+Kiosk Mode Playbook This playbook runs the kiosk_mode role.
+Podman Playbook This playbook runs the container_lifecycle role with overrides suitable for the Ignition application container.
+Ping Playbook This playbook is for testing basic connectivity - making sure that you can reach the nodes you wish to manage, and that the credentials you have given will work on them. It will not change anything on the VMs - just gather facts from them (which requires elevating to root).
+Schedules Update Project AEG GitOps This job runs every 5 minutes to update the GitOps repository associated with the project. This is necessary when any of the Ansible code (for example, the playbooks or roles associated with the pattern) changes, so that the new code is available to the AAP instance.
+Dynamic Provision Kiosk Playbook This job runs every 10 minutes to provision and configure any kiosks it finds to run the Ignition application in a podman container, and configure firefox in kiosk mode to display that application. The playbook is designed to be idempotent, so it is safe to run multiple times on the same targets; it will not make user-visible changes to those targets unless it must.
+This playbook combines the inventory_preplay and the Provision Kiosk Playbook.
+Execution Environment The pattern includes an execution environment definition that can be found here.
+The execution environment includes some additional collections beyond what is provided in the Default execution environment, including:
+fedora.linux_system_roles containers.podman community.okd The execution environment definition is provided if you want to customize or change it; if so, you should also change the Execution Environment attributes of the Templates (in the load script, those attributes are set by the variables aap_execution_environment and aap_execution_environment_image).
+Roles included in the pattern kiosk_mode This role is responsible does the following:
+RHEL node registration Installation of GUI packages Installation of Firefox Configuration of Firefox kiosk mode container_lifecycle This role is responsible for:
+Downloading and running a podman image on the system (and configure it to auto-update) Setting the container up to run at boot time Passing any other runtime arguments to the container. In this container&rsquo;s case, that includes specifying an admin password override. Extra Playbooks in the Pattern inventory_preplay.yml This playbook is designed to be included in other plays; its purpose is to discover the desired inventory and add those hosts to inventory at runtime. It uses a kubernetes query via the cluster-admin kube config file.
+Provision Kiosk Playbook This does the work of provisioning the kiosk, which configures kiosk mode, and also installs Ignition and configures it to start at boot. It runs the kiosk_mode and container_lifecycle roles.
+Next Steps Help &amp; Feedback Report Bugs `,url:"https://validatedpatterns.io/patterns/ansible-edge-gitops/ansible-automation-platform/",breadcrumb:"/patterns/ansible-edge-gitops/ansible-automation-platform/"},"https://validatedpatterns.io/contribute/creating-a-pattern/":{title:"Creating a pattern",tags:[],content:` The validated patterns community has relied on existing architectures that have been successfully deployed in an enterprise. The architecture itself is a best practice in assembling technologies and projects to provide a working solution. How that solution is deployed and managed is a different matter. It may have evolved over time and may have grown in its deployment such that ongoing maintenance is not sustainable.
+The validated patterns framework is much more of a best practice of structuring the various configuration assets and integrating with GitOps and DevOps tools.
+Therefore the question really is: how do I move my successful architecture solution into a sustainable GitOps/DevOps framework? And that is what we are going to address this section.
+So how do you take a current application workload and move it to the Validated Pattern framework? One of the first things that you should do is look at the current implementation of your workload and identify the kubernetes manifests that are involved in order to run the workloads.
+Prerequisites Please make sure you have read the background section, including the structure section.
+You’re probably not starting from scratch The validated patterns community has relied on existing architectures that have been successfully deployed in an enterprise. The architecture itself is a best practice in assembling technologies and projects to provide a working solution. How that solution is deployed and managed is a different matter. It may have evolved over time and may have grown in its deployment such that ongoing maintenance is not sustainable.
+The validated patterns framework is much more of a best practice of structuring the various configuration assets and integrating with GitOps and DevOps tools.
+Therefore the question really is: How do I move my successful architecture solution into a sustainable GitOps/DevOps framework? And that is what we are going to do in this section.
+Requirements for creating a new pattern The patterns framework requires some artifacts like OpenShift GitOps (ArgoCD) in order to provide the GitOps automation. All existing patterns use OpenShift GitOps as a starting point. The multicloud-gitops pattern is the most fundamental of patterns and therefore it is recommended to use it as a base pattern. I.e Create a new pattern based on it.
+Create a new branch on your new pattern to perform the initial changes.
+Deploy the initial new pattern pattern to the cluster.
+Moving to the validated patterns framework One of the first things that you should do is look at your current implementation of your workload and identify the Kubernetes manifests that are involved in order to run the workloads.
+When and how to use values- files There are 4 values files that make up any Validated Pattern. The values files are:
+values-&lt;main-hub&gt;.yaml (e.g. values-datacenter.yaml)
+values-&lt;edge&gt;.yaml (e.g. values-edge-site.yaml, values-factory.yaml, values-development.yaml, etc.)
+values-global.yaml (used to override global values across clusters)
+values-secrets.yaml (NEVER commit this to github, gitlab etc. This file should be in a safe directory on your laptop)
+Operators into framework We begin our journey by identifying what application services are needed to run the workload. The Cloud Native Operator framework provides a way of managing the lifecycle of application services that are needed by the application workload. The validated pattern framework gives you a way to describe these Operators in a values file that is specific to your pattern and the site type.
+So for example if we wish deploy Advanced Cluster Management, AMQ (messaging) and AMQ Streams (Kafka) in our datacenter, we would make the following subscription entries in our values-datacenter.yaml file:
+namespaces: - open-cluster-management - my-application - backend-storage subscriptions: - name: advanced-cluster-management namespace: open-cluster-management channel: release-2.3 csv: advanced-cluster-management.v2.3.2 - name: amq-streams namespace: my-application channel: amq-streams-1.7.x csv: amqstreams.v1.7.1 - name: amq-broker namespace: my-application channel: 7.8.x csv: amq-broker-operator.v7.8.1-opr-3 This tells the framework which Operators are needed and what namespace they should be deployed in.
+Grouping applications for OpenShift GitOps In the same values- file we need to inform OpenShift GitOps (ArgoCD) what applications to deploy and where the Helm Charts are so that they can be applied to the deployment and watched for future changes.
+When using GitOps, specifically OpenShift GitOps (ArgoCD), it makes sense to break up applications into different areas of concern, i.e. projects. For example, the main applications for the datacenter might be grouped separately from some storage components:
+projects: - datacenter - storage applications: - name: acm namespace: open-cluster-management project: datacenter path: common/acm ignoreDifferences: - group: internal.open-cluster-management.io kind: ManagedClusterInfo jsonPointers: - /spec/loggingCA - name: central-kafka namespace: backend-storage project: storage path: charts/datacenter/kafka ignoreDifferences: - group: apps kind: Deployment jsonPointers: - /spec/replicas - group: route.openshift.io kind: Route jsonPointers: - /status - group: image.openshift.io kind: ImageStream jsonPointers: - /spec/tags - group: apps.openshift.io kind: DeploymentConfig jsonPointers: - /spec/template/spec/containers/0/image - name: cool-app namespace: my-application project: datacenter path: charts/datacenter/my-app plugin: name: helm-with-kustomize In the above example acm (ACM) is part of the main datacenter deployment, as is cool-app. However, central-kafka is part of backend-storage. All these deployment are on the same datacenter cluster.
+The path: tag tells OpenShift GitOps where to find the Helm charts needed to deploy this application (refer back to the charts directory description for more details). OpenShift GitOps will continuously monitor for changes to artifacts in that location for updates to apply.
+Each different site type would have its own values- file listing subscriptions and applications.
+Kustomize to framework Kustomize can still be used within the framework but it will be driven by Helm. If you have a lot of kustomization.yaml, you may not need to refactor all of it. However, you will need a Helm chart to drive it and you will need to check for names and paths etc. that you may need to parameterize using the Helm templates capabilities.
+For example, the original Argo CD subscription YAML from one of the patterns looked like this:
+apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: argocd-operator namespace: argocd spec: channel: alpha installPlanApproval: Manual name: argocd-operator source: community-operators sourceNamespace: openshift-marketplace startingCSV: argocd-operator.v0.0.11 While we could have continued to use the ArgoCD community operator, we instead transitioned to using OpenShift GitOps, the Red Hat supported product. But this static subscription would not allow updates for continuous integration of new versions. And you’ll remember from the Operators section above that we specify channel names as part of the subscription of operators. So we can instead using something like this (understanding the move to openshift-gitops-operator instead of ArgoCD).
+apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: openshift-gitops-operator namespace: openshift-operators labels: operators.coreos.com/openshift-gitops-operator.openshift-operators: &#34;&#34; spec: channel: {{ .Values.main.gitops.channel }} installPlanApproval: {{ .Values.main.options.installPlanApproval }} name: openshift-gitops-operator source: redhat-operators sourceNamespace: openshift-marketplace {{- if .Values.main.options.useCSV }} startingCSV: openshift-gitops-operator.{{ .Values.main.gitops.csv }} {{- end }} Size matters If things are taking a long time to deploy, use the OpenShift console to check on memory and other potential capacity issues with the cluster. If running in a cloud you may wish to up the machine size. Check the sizing charts.
+`,url:"https://validatedpatterns.io/contribute/creating-a-pattern/",breadcrumb:"/contribute/creating-a-pattern/"},"https://validatedpatterns.io/patterns/multicloud-gitops-amx/mcg-amx-imperative-actions/":{title:"Imperative actions",tags:[],content:` Using kubernetes cronjobs to apply imperative actions There is currently no way within Argo CD to apply an imperative action against a cluster. However, you can declaratively apply changes to a cluster using kubernetes cronjob resources. Customers can use their Ansible playbooks to take action against a cluster if necessary.
+The authors of the Ansible playbooks and roles must ensure that the playbooks are idempotent because they get applied through cronjobs which are set to run every 10 minutes.
+Adding your playbooks to the pattern requires the following:
+Move your Ansible configurations to the appropriate directory under Ansible in your forked repository.
+Define your job as a list, for example:
+imperative: # NOTE: We *must* use lists and not hashes. As hashes lose ordering once parsed by helm # The default schedule is every 10 minutes: imperative.schedule # Total timeout of all jobs is 1h: imperative.activeDeadlineSeconds # imagePullPolicy is set to always: imperative.imagePullPolicy # For additional overrides that apply to the jobs, please refer to the README located in # the top level of this repository. jobs: - name: regional-ca # Ansible playbook to be run playbook: ansible/playbooks/on-hub-get-regional-ca.yml # per playbook timeout in seconds timeout: 234 # verbosity: &#34;-v&#34; Additional job customizations The pattern includes override parameters to provide further customization. Refer to the list below for the available overrides.
+imperative: jobs: [] # This image contains Ansible + kubernetes.core by default and is used to run the jobs image: registry.redhat.io/ansible-automation-platform-22/ee-supported-rhel8:latest namespace: &#34;imperative&#34; # configmap name in the namespace that will contain all helm values valuesConfigMap: &#34;helm-values-configmap&#34; cronJobName: &#34;imperative-cronjob&#34; jobName: &#34;imperative-job&#34; imagePullPolicy: Always # This is the maximum timeout of all the jobs (1h) activeDeadlineSeconds: 3600 # By default we run this every 10minutes schedule: &#34;*/10 * * * *&#34; # Schedule used to trigger the vault unsealing (if explicitly enabled) # Set to run every 9 minutes in order for load-secrets to succeed within # a reasonable amount of time (it waits up to 15 mins) insecureUnsealVaultInsideClusterSchedule: &#34;*/9 * * * *&#34; # Increase Ansible verbosity with &#39;-v&#39; or &#39;-vv..&#39; verbosity: &#34;&#34; serviceAccountCreate: true # service account to be used to run the cron pods serviceAccountName: imperative-sa clusterRoleName: imperative-cluster-role clusterRoleYaml: &#34;&#34; roleName: imperative-role roleYaml: &#34;&#34; `,url:"https://validatedpatterns.io/patterns/multicloud-gitops-amx/mcg-amx-imperative-actions/",breadcrumb:"/patterns/multicloud-gitops-amx/mcg-amx-imperative-actions/"},"https://validatedpatterns.io/patterns/multicloud-gitops-qat/mcg-qat-imperative-actions/":{title:"Imperative actions",tags:[],content:` Using kubernetes cronjobs to apply imperative actions There is currently no way within Argo CD to apply an imperative action against a cluster. However, you can declaratively apply changes to a cluster using kubernetes cronjob resources. Customers can use their Ansible playbooks to take action against a cluster if necessary.
+The authors of the Ansible playbooks and roles must ensure that the playbooks are idempotent because they get applied through cronjobs which are set to run every 10 minutes.
+Adding your playbooks to the pattern requires the following:
+Move your Ansible configurations to the appropriate directory under Ansible in your forked repository.
+Define your job as a list, for example:
+imperative: # NOTE: We *must* use lists and not hashes. As hashes lose ordering once parsed by helm # The default schedule is every 10 minutes: imperative.schedule # Total timeout of all jobs is 1h: imperative.activeDeadlineSeconds # imagePullPolicy is set to always: imperative.imagePullPolicy # For additional overrides that apply to the jobs, please refer to the README located in # the top level of this repository. jobs: - name: regional-ca # Ansible playbook to be run playbook: ansible/playbooks/on-hub-get-regional-ca.yml # per playbook timeout in seconds timeout: 234 # verbosity: &#34;-v&#34; Additional job customizations The pattern includes override parameters to provide further customization. Refer to the list below for the available overrides.
+imperative: jobs: [] # This image contains Ansible + kubernetes.core by default and is used to run the jobs image: registry.redhat.io/ansible-automation-platform-22/ee-supported-rhel8:latest namespace: &#34;imperative&#34; # configmap name in the namespace that will contain all helm values valuesConfigMap: &#34;helm-values-configmap&#34; cronJobName: &#34;imperative-cronjob&#34; jobName: &#34;imperative-job&#34; imagePullPolicy: Always # This is the maximum timeout of all the jobs (1h) activeDeadlineSeconds: 3600 # By default we run this every 10minutes schedule: &#34;*/10 * * * *&#34; # Schedule used to trigger the vault unsealing (if explicitly enabled) # Set to run every 9 minutes in order for load-secrets to succeed within # a reasonable amount of time (it waits up to 15 mins) insecureUnsealVaultInsideClusterSchedule: &#34;*/9 * * * *&#34; # Increase Ansible verbosity with &#39;-v&#39; or &#39;-vv..&#39; verbosity: &#34;&#34; serviceAccountCreate: true # service account to be used to run the cron pods serviceAccountName: imperative-sa clusterRoleName: imperative-cluster-role clusterRoleYaml: &#34;&#34; roleName: imperative-role roleYaml: &#34;&#34; `,url:"https://validatedpatterns.io/patterns/multicloud-gitops-qat/mcg-qat-imperative-actions/",breadcrumb:"/patterns/multicloud-gitops-qat/mcg-qat-imperative-actions/"},"https://validatedpatterns.io/patterns/multicloud-gitops-sgx-hello-world/mcg-sgx-hello-world-imperative-actions/":{title:"Imperative actions",tags:[],content:` Using kubernetes cronjobs to apply imperative actions There is currently no way within Argo CD to apply an imperative action against a cluster. However, you can declaratively apply changes to a cluster using kubernetes cronjob resources. Customers can use their Ansible playbooks to take action against a cluster if necessary.
+The authors of the Ansible playbooks and roles must ensure that the playbooks are idempotent because they get applied through cronjobs which are set to run every 10 minutes.
+Adding your playbooks to the pattern requires the following:
+Move your Ansible configurations to the appropriate directory under Ansible in your forked repository.
+Define your job as a list, for example:
+imperative: # NOTE: We *must* use lists and not hashes. As hashes lose ordering once parsed by helm # The default schedule is every 10 minutes: imperative.schedule # Total timeout of all jobs is 1h: imperative.activeDeadlineSeconds # imagePullPolicy is set to always: imperative.imagePullPolicy # For additional overrides that apply to the jobs, please refer to the README located in # the top level of this repository. jobs: - name: regional-ca # Ansible playbook to be run playbook: ansible/playbooks/on-hub-get-regional-ca.yml # per playbook timeout in seconds timeout: 234 # verbosity: &#34;-v&#34; Additional job customizations The pattern includes override parameters to provide further customization. Refer to the list below for the available overrides.
+imperative: jobs: [] # This image contains Ansible + kubernetes.core by default and is used to run the jobs image: registry.redhat.io/ansible-automation-platform-22/ee-supported-rhel8:latest namespace: &#34;imperative&#34; # configmap name in the namespace that will contain all helm values valuesConfigMap: &#34;helm-values-configmap&#34; cronJobName: &#34;imperative-cronjob&#34; jobName: &#34;imperative-job&#34; imagePullPolicy: Always # This is the maximum timeout of all the jobs (1h) activeDeadlineSeconds: 3600 # By default we run this every 10minutes schedule: &#34;*/10 * * * *&#34; # Schedule used to trigger the vault unsealing (if explicitly enabled) # Set to run every 9 minutes in order for load-secrets to succeed within # a reasonable amount of time (it waits up to 15 mins) insecureUnsealVaultInsideClusterSchedule: &#34;*/9 * * * *&#34; # Increase Ansible verbosity with &#39;-v&#39; or &#39;-vv..&#39; verbosity: &#34;&#34; serviceAccountCreate: true # service account to be used to run the cron pods serviceAccountName: imperative-sa clusterRoleName: imperative-cluster-role clusterRoleYaml: &#34;&#34; roleName: imperative-role roleYaml: &#34;&#34; `,url:"https://validatedpatterns.io/patterns/multicloud-gitops-sgx-hello-world/mcg-sgx-hello-world-imperative-actions/",breadcrumb:"/patterns/multicloud-gitops-sgx-hello-world/mcg-sgx-hello-world-imperative-actions/"},"https://validatedpatterns.io/patterns/multicloud-gitops-sgx/mcg-sgx-imperative-actions/":{title:"Imperative actions",tags:[],content:` Using kubernetes cronjobs to apply imperative actions There is currently no way within Argo CD to apply an imperative action against a cluster. However, you can declaratively apply changes to a cluster using kubernetes cronjob resources. Customers can use their Ansible playbooks to take action against a cluster if necessary.
+The authors of the Ansible playbooks and roles must ensure that the playbooks are idempotent because they get applied through cronjobs which are set to run every 10 minutes.
+Adding your playbooks to the pattern requires the following:
+Move your Ansible configurations to the appropriate directory under Ansible in your forked repository.
+Define your job as a list, for example:
+imperative: # NOTE: We *must* use lists and not hashes. As hashes lose ordering once parsed by helm # The default schedule is every 10 minutes: imperative.schedule # Total timeout of all jobs is 1h: imperative.activeDeadlineSeconds # imagePullPolicy is set to always: imperative.imagePullPolicy # For additional overrides that apply to the jobs, please refer to the README located in # the top level of this repository. jobs: - name: regional-ca # Ansible playbook to be run playbook: ansible/playbooks/on-hub-get-regional-ca.yml # per playbook timeout in seconds timeout: 234 # verbosity: &#34;-v&#34; Additional job customizations The pattern includes override parameters to provide further customization. Refer to the list below for the available overrides.
+imperative: jobs: [] # This image contains Ansible + kubernetes.core by default and is used to run the jobs image: registry.redhat.io/ansible-automation-platform-22/ee-supported-rhel8:latest namespace: &#34;imperative&#34; # configmap name in the namespace that will contain all helm values valuesConfigMap: &#34;helm-values-configmap&#34; cronJobName: &#34;imperative-cronjob&#34; jobName: &#34;imperative-job&#34; imagePullPolicy: Always # This is the maximum timeout of all the jobs (1h) activeDeadlineSeconds: 3600 # By default we run this every 10minutes schedule: &#34;*/10 * * * *&#34; # Schedule used to trigger the vault unsealing (if explicitly enabled) # Set to run every 9 minutes in order for load-secrets to succeed within # a reasonable amount of time (it waits up to 15 mins) insecureUnsealVaultInsideClusterSchedule: &#34;*/9 * * * *&#34; # Increase Ansible verbosity with &#39;-v&#39; or &#39;-vv..&#39; verbosity: &#34;&#34; serviceAccountCreate: true # service account to be used to run the cron pods serviceAccountName: imperative-sa clusterRoleName: imperative-cluster-role clusterRoleYaml: &#34;&#34; roleName: imperative-role roleYaml: &#34;&#34; `,url:"https://validatedpatterns.io/patterns/multicloud-gitops-sgx/mcg-sgx-imperative-actions/",breadcrumb:"/patterns/multicloud-gitops-sgx/mcg-sgx-imperative-actions/"},"https://validatedpatterns.io/patterns/multicloud-gitops/mcg-imperative-actions/":{title:"Imperative actions",tags:[],content:` Using kubernetes cronjobs to apply imperative actions There is currently no way within Argo CD to apply an imperative action against a cluster. However, you can declaratively apply changes to a cluster using kubernetes cronjob resources. Customers can use their Ansible playbooks to take action against a cluster if necessary.
+The authors of the Ansible playbooks and roles must ensure that the playbooks are idempotent because they get applied through cronjobs which are set to run every 10 minutes.
+Adding your playbooks to the pattern requires the following:
+Move your Ansible configurations to the appropriate directory under Ansible in your forked repository.
+Define your job as a list, for example:
+imperative: # NOTE: We *must* use lists and not hashes. As hashes lose ordering once parsed by helm # The default schedule is every 10 minutes: imperative.schedule # Total timeout of all jobs is 1h: imperative.activeDeadlineSeconds # imagePullPolicy is set to always: imperative.imagePullPolicy # For additional overrides that apply to the jobs, please refer to the README located in # the top level of this repository. jobs: - name: regional-ca # Ansible playbook to be run playbook: ansible/playbooks/on-hub-get-regional-ca.yml # per playbook timeout in seconds timeout: 234 # verbosity: &#34;-v&#34; Additional job customizations The pattern includes override parameters to provide further customization. Refer to the list below for the available overrides.
+imperative: jobs: [] # This image contains Ansible + kubernetes.core by default and is used to run the jobs image: registry.redhat.io/ansible-automation-platform-22/ee-supported-rhel8:latest namespace: &#34;imperative&#34; # configmap name in the namespace that will contain all helm values valuesConfigMap: &#34;helm-values-configmap&#34; cronJobName: &#34;imperative-cronjob&#34; jobName: &#34;imperative-job&#34; imagePullPolicy: Always # This is the maximum timeout of all the jobs (1h) activeDeadlineSeconds: 3600 # By default we run this every 10minutes schedule: &#34;*/10 * * * *&#34; # Schedule used to trigger the vault unsealing (if explicitely enabled) # Set to run every 9 minutes in order for load-secrets to succeed within # a reasonable amount of time (it waits up to 15 mins) insecureUnsealVaultInsideClusterSchedule: &#34;*/9 * * * *&#34; # Increase Ansible verbosity with &#39;-v&#39; or &#39;-vv..&#39; verbosity: &#34;&#34; serviceAccountCreate: true # service account to be used to run the cron pods serviceAccountName: imperative-sa clusterRoleName: imperative-cluster-role clusterRoleYaml: &#34;&#34; roleName: imperative-role roleYaml: &#34;&#34; `,url:"https://validatedpatterns.io/patterns/multicloud-gitops/mcg-imperative-actions/",breadcrumb:"/patterns/multicloud-gitops/mcg-imperative-actions/"},"https://validatedpatterns.io/patterns/devsecops/secure-supply-chain-demo/":{title:"Multicluster DevSecOps Demo",tags:[],content:`Demonstrating Multicluster DevSecOps Background Up until now the Multicluster DevSecOps validated pattern has focused primarily on successfully deploying the architectural pattern components on the three different clusters. Now it is time to see DevSecOps in action as we step through a number of pipeline demonstrations to see the secure supply chain in action.
+Prerequisite preparation Make sure to have hub, development and production environments setup. It is possible to set up a production environment on your hub cluster if you wish to use only two clusters.
+Local laptop/workstation Make sure you have git and OpenShift&rsquo;s oc command-line clients.
+OpenShift Cluster Make sure you have the kubeadmin administrator login for the data center cluster. Use this or the kubeconfig (export the path) to provide administrator access to your data center cluster. It is not required that you have access to the edge (factory) clusters. GitOps and DevOps will take care of the edge clusters.
+GitHub account You will need to login into GitHub and be able to fork two repositories.
+validatedpatterns/multicluster-devsecops hybrid-cloud-patterns/chat-client Pipeline Demos Pipeline 1: Build &amp; Deploy Running this pipeline shows how a build and deploy can run easily and push an image to production and everything looks fine. There are many development environments that run in this &ldquo;trusted&rdquo; mode today.
+However the built image is never scanned. And in the next pipeline we see that the same image that was deployed in Pipeline 1 is actually not secure and should never have been deployed.
+TBD - screen shots
+Pipeline 2: Build &amp; Scan with Failure Pipeline 2 is the same as Pipeline 1 except that the image is scanned and found to fail the scan. The image is NOT pushed to a registry and therefore not deployed to production.
+TBD - screen shots
+Pipeline 3: Build &amp; Scan with Success Pipeline 3 builds an image that successfully scans without issue. This shows the steps to add a scan task to the pipeline.
+TBD - screen shots
+Pipeline 4: Build, Scan, Sign and Push to Prod Pipeline 4 demonstrates a more complete pipeline that builds, scans and also signs the image before pushing.
+Pipeline 4 is the preferred DevSecOps approach and can be modified to include more security based tasks. E.g. when using a base image for a build, the signature of that image can be checked before the build step even starts.
+TBD - screen shots
+`,url:"https://validatedpatterns.io/patterns/devsecops/secure-supply-chain-demo/",breadcrumb:"/patterns/devsecops/secure-supply-chain-demo/"},"https://validatedpatterns.io/learn/quickstart/":{title:"Patterns quick start",tags:[],content:` Patterns quick start Each pattern can be deployed using the command line. The only requirement is to have git and podman installed. See the Prerequisite installation instructions for more information.
+Patterns deployment requires several tools including Helm to install. However, the validated patterns framework removes the need to install and maintain these tools. The pattern.sh script uses a container which includes the necessary tools. The use of that container is why you need to install podman.
+Check the values-*.yaml for changes that are needed before deployment. After changing the values-*.yaml files where needed and pushing them to your git repository, you can run ./pattern.sh make install from your local repository directory and that will deploy the datacenter/hub cluster for a pattern. Edge clusters are deployed by joining/importing them into ACM on the hub.
+Alternatively to the ./pattern.sh make install method, you can use the validated pattern operator available in the OpenShift console.
+For information on using the Validated Patterns Operator, see Using the Validated Pattern Operator.
+Follow any other post-install instructions for the pattern on that pattern’s Getting started page.
+Prerequisite installation instructions Tested Operating systems The following instructions have been tested on the following operating systems:
+Red Hat Enterprise Linux 8 and 9
+CentOS 8 and 9
+Fedora 36 and onwards
+Debian Bookworm
+Ubuntu 22.04
+Mac OSX Big Sur and onwards
+Red Hat Enterprise Linux 8 and 9 Make sure that you have both the appstream and the baseos repositories configured. For example on RHEL 8 you will get the following:
+sudo dnf repolist Updating Subscription Management repositories. repo id repo name rhel-8-for-x86_64-appstream-rpms Red Hat Enterprise Linux 8 for x86_64 - AppStream (RPMs) rhel-8-for-x86_64-baseos-rpms Red Hat Enterprise Linux 8 for x86_64 - BaseOS (RPMs) Install podman and git:
+sudo dnf install -y podman git Fedora Install podman and git:
+sudo dnf install -y podman git Debian and derivatives Install podman and git:
+sudo apt-get install -y podman git Mac OSX Install podman and git:
+/bin/bash -c &#34;$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)&#34; brew install podman git # Containers on MacOSX run in a VM which is managed by &#34;podman machine&#34; commands podman machine init -v \${HOME}:\${HOME} -v /private/tmp/:/private/tmp podman machine start `,url:"https://validatedpatterns.io/learn/quickstart/",breadcrumb:"/learn/quickstart/"},"https://validatedpatterns.io/patterns/gaudi-rag-chat-qna/gaudi-rag-chat-qna-troubleshooting/":{title:"Troubleshooting",tags:[],content:` Troubleshooting common Pattern Deployment issues Problem Validated Pattern installation process is stuck on deploying Vault
+Solution Most common reason of this is that prerequisites are not satisfied i.e. Image Registry is not set up or CephFs is not set as a default StorageClass. Please refer to section Getting started → Prerequisites and make sure all is done before proceeding to pattern deployment.
+Problem Downloading AI model Llama-2-70b-chat-hf using download-model Jupyter notebook is failing or TGI deployment fails after model is downloaded
+Solution Most often this is due to some network errors while downloading the model. If not sure if whole model was downloaded, please clear bucket model-bucket in RGW storage using aws-cli or any other method, and repeat process of downloading the model.
+Problem Builds of OPEA chat resources are failing, they cannot pull images
+Solution If all Build resources are failing, because of pulling image errors please makes ure that there is no proxy issue. Refer to section Getting started → Procedure. Also make sure that Image Registry is properly set up.
+Problem TGI or TEI pods are showing errors
+Solution Consult Troubleshooting PyTorch Model documentation for general Gaudi 2 troubleshooting steps. Gathering extended logs might be helpful, as mentioned in troubleshooting steps for &#34;RuntimeError: tensor does not have a device&#34;. Container directory /var/log/habana_logs should then be inspected to see logs from SynapseAI and other components.
+Problem TGI shows &#34;Cannot allocate connection&#34; or &#34;The condition [ isNicUp(port) ] failed.&#34; errors
+Solution Review Disable/Enable NICs guide. Standalone machines that are not configured for scale up with Gaudi 2 NICs connected to a switch require running &#34;To disable Gaudi external NICs, run the following command&#34; in the &#34;Disable/Enable Gaudi 2 External NICs&#34; section.
+`,url:"https://validatedpatterns.io/patterns/gaudi-rag-chat-qna/gaudi-rag-chat-qna-troubleshooting/",breadcrumb:"/patterns/gaudi-rag-chat-qna/gaudi-rag-chat-qna-troubleshooting/"},"https://validatedpatterns.io/patterns/industrial-edge/troubleshooting/":{title:"Troubleshooting",tags:[],content:`Troubleshooting Our Issue Tracker Installation-phase Failures The framework for deploying the applications and their operators has been made easy for the user by using OpenShift GitOps for continuous deployment (Argo CD). It takes time to deploy everything. You may have to go back and forth between the OpenShift cluster console and the OpenShift GitOps console to check on applications and operators being up and in a ready state.
+The applications deployment for the main data center are as follows. First OpenShift GitOps operator will deploy. See the OpenShift Console to see that it is running. Then OpenShift GitOps takes over the rest of the deployment. It deploys the following applications
+Advanced Cluster Management operator in the application acm. this will manage the edge clusters Open Data Hub in the application odh for the data science components. OpenShift Pipelines is deployed in the application pipelines AMQ Streams is deployed to manage data coming from factories and stored in a data lake. The data lake uses S3 based storage and is deployed in the central-s3 application Testing at the data center is managed by the manuela-test application Make sure that all these applications are Healthy 💚 and Synced ✅ in the OpenShift GitOps console. If in a state other than Healthy (Progressing, Degraded, Missing, Unknown') then it&rsquo;s time to dive deeper into that application and see what has happened.
+The applications deployed on the factory (edge) cluster are as follows. After a successful importing [1] a factory cluster to the main ACM hub, you should check in the factory cluster&rsquo;s OpenShift UI to see if the projects open-cluster-manager-agent and open-cluster-manager-agent-addons are running. When these are deployed then OpenShift GitOps operator will be deployed on the cluster. From there OpenShift GitOps deploys the following applications:
+datalake application sets streams to the data center. stormshift sets up application and AMQ integration components odh sets up the AI/ML models that have been developed by the data scientists. [1] ACM has different ways of describing this process based on which tool you are using. Attach, Join, Import are terms associated with bringing a cluster under the management of a hub cluster.
+Install loop does not complete Symptom: make install does not complete in a timely fashion (~10 minutes from start). Status messages keep scrolling Cause: One of the conditions for installation has not been completed. See below for details.
+Resolution: Re-run the failing step outside the loop. See below for how.
+It is safe to exit the loop (via Ctrl-C, for example) and run the operations separately.
+The industrial edge pattern runs two post-install operations after creating the main ArgoCD applications:
+Extracting the secret from the datacenter ArgoCD instance for use in the Pipelines
+This depends on the installation of both the cluster-wide GitOps operator, and the installation of an instance in the datacenter namespace. The logic is controlled here (where the parameters are set) and here, which does the interactions with the cluster (to extract the secret and create a resource in manuela-ci).
+This task runs first, and if it does not complete, the seed pipeline will not start either. Things to check:
+Check to make sure the operators are installing in your cluster correctly. Ensure you have enough capacity in your cluster to run all the needed resources. You can attempt to run the extraction outside of make install. Ensure that you have logged in to the cluster (via oc login or by exporting a suitable KUBECONFIG:
+Run make secret in the base directory of your industrial-edge repository fork. Running the &ldquo;seed&rdquo; pipeline to populate the image registries for the manuela-tst-all namespace and the edge/factory namespaces (manuela-stormshift-messaging, manuela-line-dashboard etc.).
+It is important that the seed pipeline run and complete because the applications will be &ldquo;degraded&rdquo; until they can deploy the images, and seed is what populates the images in the local cluster registries and instructs the applications to use them.
+The seed pipeline depends on the Pipelines operator to be installed, as well as the tkn Task (in the manuela-ci namespace). The script checks for both. (make install calls the sleep-seed target, which checks for the resources before trying to kick off a seed pipeline run.
+Run make seed in the base directory of your industrial edge repository fork. This kicks off the pipeline without checking for its dependencies. This target does not ensure that the seed pipeline completes. See below on how to re-run seed if the seed pipeline fails for any reason. It is safe to run the seed pipeline multiple times - each time it runs it will update the image targets for each of the images in both test (manuela-tst-all) and production (manuela-stormshift-messaging etc).
+Subscriptions not being installed Symptom: Install seems to &ldquo;freeze&rdquo; at a specific point. Expected operators do not install in the cluster Cause: It is possible an operator was requested to be installed that isn&rsquo;t allowed to be installed on this version of OpenShift.
+Resolution: In general, use the project-supplied global.options.UseCSV setting of False. This requests the current, best version of the operator available. If a specific CSV (Cluster Service Version) is requested but unavailable, that operator will not be able to install at all, and when an operator fails to install, that may have a cascading effect on other operators.
+Potential (Known) Operational Issues Pipeline Failures Symptom: &ldquo;User not found&rdquo; error in first stage of pipeline run Cause: Despite the message, the error is most likely that you don&rsquo;t have a fork of manuela-dev.
+Resolution: Fork manuela-dev into your namespace in GitHub and run make seed.
+Symptom: Intermittent failures in Pipeline stages Some sample errors:
+level=error msg=&#34;Error while applying layer: ApplyLayer io: read/write on closed pipe stdout: {\\&#34;layerSize\\&#34;:7301}\\n stderr: &#34; error creating build container: Error committing the finished image: error adding layer with blob time=&#34;2021-09-29T18:48:27Z&#34; level=fatal msg=&#34;Error trying to reuse blob sha256:235f9e6f3559c04d5ee09b613dcab06dbc03ceb93b65ce364afe35c03fd53574 at destination: failed to read from destination repository martjack/iot-software-sensor: 500 (Internal Server Error) I1006 22:07:47.908257 14 request.go:645] Throttling request took 1.195150708s, request: GET:https://172.30.0.1:443/apis/autoscaling.openshift.io/v1?timeout=32s PipelineRun started: seed-iot-software-sensor-run-cpzzv Waiting for logs to be available... E1006 22:08:27.106369 14 runtime.go:78] Observed a panic: &#34;send on closed channel&#34; (send on closed channel) goroutine 487 [running]: k8s.io/apimachinery/pkg/util/runtime.logPanic(0x1b40ee0, 0x1fe47b0) /workspace/pkg/mod/k8s.io/apimachinery@v0.19.7/pkg/util/runtime/runtime.go:74 +0x95 k8s.io/apimachinery/pkg/util/runtime.HandleCrash(0x0, 0x0, 0x0) /workspace/pkg/mod/k8s.io/apimachinery@v0.19.7/pkg/util/runtime/runtime.go:48 +0x89 panic(0x1b40ee0, 0x1fe47b0) When this happens, the pipeline may not entirely stop running. It is safe to stop/cancel the pipeline run, and desirable to do so, since multiple pipelines attempting to change the repository at the same time could cause more failures.
+Resolution: Run make seed in the root of the repository OR re-run the failed pipeline segment (e.g. seed-iot-frontend or seed-iot-consumer).
+We&rsquo;re looking into better long-term fixes for a number of the situations that can cause these situations as #40.
+Symptom: Error in &ldquo;push-*&rdquo; pipeline tasks Cause: Multiple processes or people were trying to make changes to the repository at the same time. The state of the repository changed in the middle of the process in such a way that the update was not a &ldquo;fast-forward&rdquo; in git terms.
+Resolution: Re-run the failed pipeline segment OR run make seed from the root of your fork of the industrial-edge repository.
+It is also possible that multiple pipelines were running at the same time and were making conflicting changes. We recommend running one pipeline at a time.
+Symptom: Pipelines application perpetually &ldquo;progressing&rdquo; and not showing green/healthy. May show &ldquo;degraded&rdquo; Cause: Most likely the application is missing the images that are built by the seed pipeline.
+Resolution: Run make seed from the root of your forked repository directory, which will build the images and deploy them to both test and production.
+Symptom: There is a &ldquo;spinny&rdquo; next to one of the resources in the app that never resolves Cause: Check for a PersistentVolumeClaim that is not in use.
+Resolution: Delete the unused PVC
+ArgoCD not syncing Symptom: ArgoCD shows an error and &ldquo;Unknown&rdquo; sync status Cause: A change has been made in the repository that renders invalid YAML
+Resolution: Fix the issue as identified by the error message, and commit and push the fix OR revert the last one.
+Certain changes might invalidate objects in ArgoCD, and this will prevent ArgoCD from deploying the change related to that commit. The error message for that situation might look like this (this particular change removed the Image details from the kustomization.yaml file, and we resolved it by re-adding the image entries:
+rpc error: code = Unknown desc = Manifest generation error (cached): \`/bin/bash -c helm template . --name-template \${ARGOCD_APP_NAME:0:52} -f https://github.com/claudiol/industrial-edge/raw/deployment/values-global.yaml -f https://github.com/claudiol/industrial-edge/raw/deployment/values-datacenter.yaml --set global.repoURL=$ARGOCD_APP_SOURCE_REPO_URL --set global.targetRevision=$ARGOCD_APP_SOURCE_TARGET_REVISION --set global.namespace=$ARGOCD_APP_NAMESPACE --set global.pattern=industrial-edge --set global.valuesDirectoryURL=https://github.com/claudiol/industrial-edge/raw/deployment --post-renderer ./kustomize\` failed exit status 1: Error: error while running post render on files: error while running command /tmp/https:__github.com_claudiol_industrial-edge/charts/datacenter/manuela-tst/kustomize. error output: ++ dirname /tmp/https:__github.com_claudiol_industrial-edge/charts/datacenter/manuela-tst/kustomize + BASE=/tmp/https:__github.com_claudiol_industrial-edge/charts/datacenter/manuela-tst + &#39;[&#39; /tmp/https:__github.com_claudiol_industrial-edge/charts/datacenter/manuela-tst = /tmp/https:__github.com_claudiol_industrial-edge/charts/datacenter/manuela-tst &#39;]&#39; + BASE=./ + cat + echo / /tmp/https:__github.com_claudiol_industrial-edge/charts/datacenter/manuela-tst / /tmp/https:__github.com_claudiol_industrial-edge/charts/datacenter/manuela-tst + ls -al total 44 drwxr-xr-x. 3 default root 166 Oct 6 20:59 . drwxr-xr-x. 7 default root 98 Oct 6 20:28 .. -rw-r--r--. 1 default root 1105 Oct 6 20:28 Chart.yaml -rw-r--r--. 1 default root 22393 Oct 6 20:59 helm.yaml -rw-r--r--. 1 default root 98 Oct 6 20:59 kustomization.yaml -rwxr-xr-x. 1 default root 316 Oct 6 20:28 kustomize -rw-r--r--. 1 default root 348 Oct 6 20:28 system-image-builder-role-binding.yaml drwxr-xr-x. 7 default root 115 Oct 6 20:28 templates -rw-r--r--. 1 default root 585 Oct 6 20:28 values.yaml + kubectl kustomize ./ Error: json: cannot unmarshal object into Go struct field Kustomization.images of type []image.Image : exit status 1 Use --debug flag to render out invalid YAML Symptom: Applications show &ldquo;not in sync&rdquo; status in ArgoCD Cause: There is a discrepancy between what the git repository says the application should have, and how that state is realized in ArgoCD.
+The installation mechanism currently installs operators as parts of multiple applications when running on the same cluster, so it is a race condition in ArgoCD to see which one &ldquo;wins.&rdquo; This is a problem with the way we are installing the patterns. We are tracking this as #38.
+`,url:"https://validatedpatterns.io/patterns/industrial-edge/troubleshooting/",breadcrumb:"/patterns/industrial-edge/troubleshooting/"},"https://validatedpatterns.io/patterns/medical-diagnosis-amx/troubleshooting/":{title:"Troubleshooting",tags:[],content:` Understanding the Makefile The Makefile is the entrypoint for the pattern. We use the Makefile to bootstrap the pattern to the cluster. After the initial bootstrapping of the pattern, the Makefile isn’t required for ongoing operations but can often be useful when needing to make a change to a config within the pattern by running a make upgrade which allows us to refresh the bootstrap resources without having to tear down the pattern or cluster.
+About the make install and make deploy commands Running make install within the pattern application triggers a make deploy from &lt;pattern_directory&gt;/common directory. This initializes the common components of the pattern framework and install a helm chart in the default namespace. At this point, cluster services, such as Red Hat Advanced Cluster Management (RHACM) and Red Hat OpenShift GitOps are deployed.
+After components from the common directory are installed, the remaining tasks within the make install target run.
+About the make vault-init and make load-secrets commands The Medical Diagnosis pattern is integrated with HashiCorp Vault and External Secrets Operator services for secrets management within the cluster. These targets install vault from a Helm chart and load the secret (values-secret.yaml) that you created during Getting Started.
+If values-secret.yaml does not exist, make will exit with an error saying so. Furthermore, if the values-secret.yaml file does exist but is improperly formatted, Red Hat Ansible Automation Platform exits with an error about being improperly formatted. To verify the format of the secret, see Getting Started.
+About the make bootstrap and make upgrade commands The make bootstrap command is the target used for deploying the application specific components of the pattern. It is the final step in the initial make install target. You might want to consider running the make upgrade command instead of the make bootstrap command directly.
+Generally, running the make upgrade command is required when you encounter errors with the application pattern deployment. For instance, if a value was missed and the chart was not rendered correctly, executing make upgrade command after fixing the value would be necessary.
+You might want to review the Makefile for the common and Medical Diagnosis components, which are located in common/Makefile and ./Makefile respectively.
+Troubleshooting the Pattern Deployment Occasionally the pattern will encounter issues during the deployment. This can happen for any number of reasons, but most often it is because of either a change within the operator itself or something has changed in the Operator Lifecycle Manager (OLM) which determines which operators are available in the operator catalog. Generally, when an issue occurs with the OLM, the operator is unavailable for installation. To ensure that the operator is in the catalog, run the following command:
+$ oc get packagemanifests | grep &lt;operator-name&gt; When an issue occurs with the operator itself you can verify the status of the subscription and make sure that there are no warnings.An additional option is to log into the OpenShift Console, click on Operators, and check the status of the operator.
+Other issues encounter could be with a specific application within the pattern misbehaving. Most of the pattern is deployed into the xraylab-1 namespace. Other components like ODF are deployed into openshift-storage and the OpenShift Serverless Operators are deployed into knative-serving, knative-eventing namespaces.
+Use the grafana dashboard to assist with debugging and identifying the issue
+Problem No information is being processed in the dashboard
+Solution Most often this is due to the image-generator deploymentConfig needing to be scaled up. The image-generator by design is scaled to 0;
+$ oc scale -n xraylab-1 dc/image-generator --replicas=1 Alternatively, complete the following steps:
+Navigate to the Red Hat OpenShift Container Platform web console, and select Workloads → DeploymentConfigs
+Select image-generator and scale the pod to 1 or more.
+Problem When browsing to the xraylab grafana dashboard and there are no images in the right-pane, only a security warning.
+Solution The certificates for the openshift cluster are untrusted by your system. The easiest way to solve this is to open a browser and go to the s3-rgw route (oc get route -n openshift-storage), then acknowledge and accept the security warning.
+Problem In the dashboard interface, no metrics data is available.
+Solution There is likely something wrong with the Prometheus Data Source for the grafana dashboard. You can check the status of the data source by executing the following:
+$ oc get grafanadatasources -n xraylab-1 Ensure that the Prometheus data source exists and that the status is available. This could potentially be the token from the service account, for example, grafana-serviceaccount, that is provided to the data source as a bearer token.
+Problem The dashboard is showing red in the corners of the dashboard panes.
+Solution This is most likely due to the xraylab database not being available or misconfigured. Please check the database and ensure that it is functioning properly.
+Ensure that the database is populated with the correct tables:
+$ oc exec -it xraylabdb-1-&lt;uuid&gt; bash $ mysql -u root USE xraylabdb; SHOW tables; Example output Welcome to the MariaDB monitor. Commands end with ; or \\g. Your MariaDB connection id is 75 Server version: 10.3.32-MariaDB MariaDB Server Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others. Type &#39;help;&#39; or &#39;\\h&#39; for help. Type &#39;\\c&#39; to clear the current input statement. MariaDB [(none)]&gt; USE xraylabdb; Database changed MariaDB [xraylabdb]&gt; show tables; +---------------------+ | Tables_in_xraylabdb | +---------------------+ | images_anonymized | | images_processed | | images_uploaded | +---------------------+ 3 rows in set (0.000 sec) Verify the password set in the values-secret.yaml is working
+$ oc exec -it xraylabdb-1-&lt;uuid&gt; bash $ mysql -u xraylab -D xraylabdb -h xraylabdb -p &lt;provide_your_password_at_prompt&gt; If you are able to successfully login then your password has been configured correctly in vault, the external secrets operator and mounted to the database correctly.
+Problem The image-generator is scaled correctly, but the dashboard is not updating.
+Solution The serverless eventing function might not be able to fetch the notifications from ODF and therefore, not triggering the knative-serving function to scale up. You may want to check the logs of the rook-ceph-rgw-ocs-storagecluster-cephobjectstore-a-&lt;podGUID&gt; pod in the openshift-storage namespace.
+$ oc logs -n openshift-storage -f &lt;pod&gt; -c rgw You should see the PUT statement with a status code of 200
+Ensure that the kafkasource, kafkservice, and kafka topic resources are created:
+$ oc get -n xraylab-1 kafkasource Example output NAME TOPICS BOOTSTRAPSERVERS READY REASON AGE xray-images [&#34;xray-images&#34;] [&#34;xray-cluster-kafka-bootstrap.xraylab-1.svc:9092&#34;] True 23m $ oc get -n xraylab-1 kservice Example output NAME URL LATESTCREATED LATESTREADY READY REASON risk-assessment https://risk-assessment-xraylab-1.apps.&lt;SUBDOMAIN&gt; risk-assessment-00001 risk-assessment-00001 True $ oc get -n xraylab-1 kafkatopics Example output NAME CLUSTER PARTITIONS REPLICATION FACTOR READY consumer-offsets---84e7a678d08f4bd226872e5cdd4eb527fadc1c6a xray-cluster 50 1 True strimzi-store-topic---effb8e3e057afce1ecf67c3f5d8e4e3ff177fc55 xray-cluster 1 3 True strimzi-topic-operator-kstreams-topic-store-changelog---b75e702040b99be8a9263134de3507fc0cc4017b xray-cluster 1 1 True xray-images xray-cluster 1 1 True `,url:"https://validatedpatterns.io/patterns/medical-diagnosis-amx/troubleshooting/",breadcrumb:"/patterns/medical-diagnosis-amx/troubleshooting/"},"https://validatedpatterns.io/patterns/medical-diagnosis/troubleshooting/":{title:"Troubleshooting",tags:[],content:` Understanding the Makefile The Makefile is the entrypoint for the pattern. We use the Makefile to bootstrap the pattern to the cluster. After the initial bootstrapping of the pattern, the Makefile isn’t required for ongoing operations but can often be useful when needing to make a change to a config within the pattern by running a make upgrade which allows us to refresh the bootstrap resources without having to tear down the pattern or cluster.
+About the make install and make deploy commands Running make install within the pattern application triggers a make deploy from &lt;pattern_directory&gt;/common directory. This initializes the common components of the pattern framework and install a helm chart in the default namespace. At this point, cluster services, such as Red Hat Advanced Cluster Management (RHACM) and Red Hat OpenShift GitOps are deployed.
+After components from the common directory are installed, the remaining tasks within the make install target run.
+About the make vault-init and make load-secrets commands The Medical Diagnosis pattern is integrated with HashiCorp Vault and External Secrets Operator services for secrets management within the cluster. These targets install vault from a Helm chart and load the secret (values-secret.yaml) that you created during Getting Started.
+If values-secret.yaml does not exist, make will exit with an error saying so. Furthermore, if the values-secret.yaml file does exist but is improperly formatted, Red Hat Ansible Automation Platform exits with an error about being improperly formatted. To verify the format of the secret, see Getting Started.
+About the make bootstrap and make upgrade commands The make bootstrap command is the target used for deploying the application specific components of the pattern. It is the final step in the initial make install target. You might want to consider running the make upgrade command instead of the make bootstrap command directly.
+Generally, running the make upgrade command is required when you encounter errors with the application pattern deployment. For instance, if a value was missed and the chart was not rendered correctly, executing make upgrade command after fixing the value would be necessary.
+You might want to review the Makefile for the common and Medical Diagnosis components, which are located in common/Makefile and ./Makefile respectively.
+Troubleshooting the Pattern Deployment Occasionally the pattern will encounter issues during the deployment. This can happen for any number of reasons, but most often it is because of either a change within the operator itself or something has changed in the Operator Lifecycle Manager (OLM) which determines which operators are available in the operator catalog. Generally, when an issue occurs with the OLM, the operator is unavailable for installation. To ensure that the operator is in the catalog, run the following command:
+$ oc get packagemanifests | grep &lt;operator-name&gt; When an issue occurs with the operator itself you can verify the status of the subscription and make sure that there are no warnings.An additional option is to log into the OpenShift Console, click on Operators, and check the status of the operator.
+Other issues encounter could be with a specific application within the pattern misbehaving. Most of the pattern is deployed into the xraylab-1 namespace. Other components like ODF are deployed into openshift-storage and the OpenShift Serverless Operators are deployed into knative-serving, knative-eventing namespaces.
+Use the grafana dashboard to assist with debugging and identifying the issue
+Problem No information is being processed in the dashboard
+Solution Most often this is due to the image-generator deploymentConfig needing to be scaled up. The image-generator by design is scaled to 0;
+$ oc scale -n xraylab-1 dc/image-generator --replicas=1 Alternatively, complete the following steps:
+Navigate to the Red Hat OpenShift Container Platform web console, and select Workloads → DeploymentConfigs
+Select image-generator and scale the pod to 1 or more.
+Problem When browsing to the xraylab grafana dashboard and there are no images in the right-pane, only a security warning.
+Solution The certificates for the openshift cluster are untrusted by your system. The easiest way to solve this is to open a browser and go to the s3-rgw route (oc get route -n openshift-storage), then acknowledge and accept the security warning.
+Problem In the dashboard interface, no metrics data is available.
+Solution There is likely something wrong with the Prometheus Data Source for the grafana dashboard. You can check the status of the data source by executing the following:
+$ oc get grafanadatasources -n xraylab-1 Ensure that the Prometheus data source exists and that the status is available. This could potentially be the token from the service account, for example, grafana-serviceaccount, that is provided to the data source as a bearer token.
+Problem The dashboard is showing red in the corners of the dashboard panes.
+Solution This is most likely due to the xraylab database not being available or misconfigured. Please check the database and ensure that it is functioning properly.
+Ensure that the database is populated with the correct tables:
+$ oc exec -it xraylabdb-1-&lt;uuid&gt; bash $ mysql -u root USE xraylabdb; SHOW tables; Example output Welcome to the MariaDB monitor. Commands end with ; or \\g. Your MariaDB connection id is 75 Server version: 10.3.32-MariaDB MariaDB Server Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others. Type &#39;help;&#39; or &#39;\\h&#39; for help. Type &#39;\\c&#39; to clear the current input statement. MariaDB [(none)]&gt; USE xraylabdb; Database changed MariaDB [xraylabdb]&gt; show tables; +---------------------+ | Tables_in_xraylabdb | +---------------------+ | images_anonymized | | images_processed | | images_uploaded | +---------------------+ 3 rows in set (0.000 sec) Verify the password set in the values-secret.yaml is working
+$ oc exec -it xraylabdb-1-&lt;uuid&gt; bash $ mysql -u xraylab -D xraylabdb -h xraylabdb -p &lt;provide_your_password_at_prompt&gt; If you are able to successfully login then your password has been configured correctly in vault, the external secrets operator and mounted to the database correctly.
+Problem The image-generator is scaled correctly, but the dashboard is not updating.
+Solution The serverless eventing function might not be able to fetch the notifications from ODF and therefore, not triggering the knative-serving function to scale up. You may want to check the logs of the rook-ceph-rgw-ocs-storagecluster-cephobjectstore-a-&lt;podGUID&gt; pod in the openshift-storage namespace.
+$ oc logs -n openshift-storage -f &lt;pod&gt; -c rgw You should see the PUT statement with a status code of 200
+Ensure that the kafkasource, kafkservice, and kafka topic resources are created:
+$ oc get -n xraylab-1 kafkasource Example output NAME TOPICS BOOTSTRAPSERVERS READY REASON AGE xray-images [&#34;xray-images&#34;] [&#34;xray-cluster-kafka-bootstrap.xraylab-1.svc:9092&#34;] True 23m $ oc get -n xraylab-1 kservice Example output NAME URL LATESTCREATED LATESTREADY READY REASON risk-assessment https://risk-assessment-xraylab-1.apps.&lt;SUBDOMAIN&gt; risk-assessment-00001 risk-assessment-00001 True $ oc get -n xraylab-1 kafkatopics Example output NAME CLUSTER PARTITIONS REPLICATION FACTOR READY consumer-offsets---84e7a678d08f4bd226872e5cdd4eb527fadc1c6a xray-cluster 50 1 True strimzi-store-topic---effb8e3e057afce1ecf67c3f5d8e4e3ff177fc55 xray-cluster 1 3 True strimzi-topic-operator-kstreams-topic-store-changelog---b75e702040b99be8a9263134de3507fc0cc4017b xray-cluster 1 1 True xray-images xray-cluster 1 1 True `,url:"https://validatedpatterns.io/patterns/medical-diagnosis/troubleshooting/",breadcrumb:"/patterns/medical-diagnosis/troubleshooting/"},"https://validatedpatterns.io/patterns/retail/troubleshooting/":{title:"Troubleshooting",tags:[],content:"Troubleshooting Our Issue Tracker ",url:"https://validatedpatterns.io/patterns/retail/troubleshooting/",breadcrumb:"/patterns/retail/troubleshooting/"},"https://validatedpatterns.io/learn/importing-a-cluster/":{title:"Importing a cluster",tags:[],content:` Importing a managed cluster Many validated patterns require importing a cluster into a managed group. These groups have specific application sets that will be deployed and managed. Some examples are factory clusters in the Industrial Edge pattern, or development clusters in Multi-cluster DevSecOps pattern.
+Red Hat Advanced Cluster Management (RHACM) can be used to create a cluster of a specific cluster group type. You can deploy a specific cluster that way if you have RHACM set up with credentials for deploying clusters. However in many cases an OpenShift cluster has already been created and will be imported into the set of clusters that RHACM is managing.
+While you can create and deploy in this manner this section concentrates on importing an existing cluster and designating a specific managed cluster group type.
+To deploy a cluster that can be imported into RHACM, use the openshift-install program provided at console.redhat.com. You will need login credentials.
+Importing a cluster using the RHACM User Interface Getting to the RHACM user interface After ACM is installed a message regarding a &#34;Web console update is available&#34; will be displayed. Click on the &#34;Refresh web console&#34; link.
+On the upper-left side you’ll see a pull down labeled &#34;local-cluster&#34;. Select &#34;All Clusters&#34; from this pull down. This will navigate to the RHACM console and to its &#34;Clusters&#34; section
+Select the &#34;Import cluster&#34; option.
+Importing the cluster On the &#34;Import an existing cluster&#34; page, enter the cluster name (arbitrary) and choose Kubeconfig as the &#34;import mode&#34;. Add the tag clusterGroup= using the appropriate cluster group specified in the pattern. Press Import.
+Using this method, you are done. Skip to the section in your pattern documentation that describes how you can confirm the pattern deployed correctly on the managed cluster.
+Other potential import tools There are a two other known ways to join a cluster to the RHACM hub. These methods are not supported but have been tested once. The patterns team no longer tests these methods. If these methods become supported we will maintain the documentation here.
+Using the cm-cli tool
+Using the clusteradm tool
+Importing a cluster using the cm-cli tool Install the cm-cli (cm) (cluster management) command-line tool. See installation instructions here: cm-cli installation
+Obtain the KUBECONFIG file from the managed cluster.
+On the command-line login into the hub/datacenter cluster (use oc login or export the KUBECONFIG).
+Run the following command:
+cm attach cluster --cluster &lt;cluster-name&gt; --cluster-kubeconfig &lt;path-to-KUBECONFIG&gt; Importing a cluster using clusteradm tool You can also use clusteradm to join a cluster. The following instructions explain what needs to be done. clusteradm is still in testing.
+To deploy a edge cluster you will need to get the hub/datacenter cluster’s token. You will need to install clusteradm. When it is installed run the following on existing hub/datacenter cluster:
+clusteradm get token When you run the clusteradm command above it replies with the token and also shows you the command to use on the managed. Login to the managed cluster with either of the following methods:
+oc login or
+export KUBECONFIG=~/&lt;path-to-kubeconfig&gt; Then request to that the managed join the datacenter hub.
+clusteradm join --hub-token &lt;token from clusteradm get token command &gt; &lt;managed-cluster-name&gt; Back on the hub cluster accept the join request.
+clusteradm accept --clusters &lt;managed-cluster-name&gt; Designate the new cluster as a devel site If you use the command line tools above you need to explicitly indicate that the imported cluster is part of a specific clusterGroup. If you haven’t tagged the cluster as clusterGroup=&lt;managed-cluster-group&gt; then do that now. Some examples of clusterGroup are factory, devel, or prod.
+We do this by adding the label referenced in the managedSite’s clusterSelector.
+Find the new cluster.
+oc get managedclusters.cluster.open-cluster-management.io Apply the label.
+oc label managedclusters.cluster.open-cluster-management.io/&lt;your-cluster&gt; clusterGroup=&lt;managed-cluster-group&gt; `,url:"https://validatedpatterns.io/learn/importing-a-cluster/",breadcrumb:"/learn/importing-a-cluster/"},"https://validatedpatterns.io/learn/ocp-cluster-general-sizing/":{title:"OpenShift General Sizing",tags:[],content:`OpenShift General Sizing Recommended node host practices The OpenShift Container Platform node configuration file contains important options. For example, two parameters control the maximum number of pods that can be scheduled to a node: podsPerCore and maxPods.
+When both options are in use, the lower of the two values limits the number of pods on a node. Exceeding these values can result in:
+Increased CPU utilization.
+Slow pod scheduling.
+Potential out-of-memory scenarios, depending on the amount of memory in the node.
+Exhausting the pool of IP addresses.
+Resource overcommitting, leading to poor user application performance.
+In Kubernetes, a pod that is holding a single container actually uses two containers. The second container is used to set up networking prior to the actual container starting. Therefore, a system running 10 pods will actually have 20 containers running.
+podsPerCore sets the number of pods the node can run based on the number of processor cores on the node. For example, if podsPerCore is set to 10 on a node with 4 processor cores, the maximum number of pods allowed on the node will be 40.
+kubeletConfig: podsPerCore: 10 Setting podsPerCore to 0 disables this limit. The default is 0. podsPerCore cannot exceed maxPods.
+maxPods sets the number of pods the node can run to a fixed value, regardless of the properties of the node.
+kubeletConfig: maxPods: 250 For more information about sizing and Red Hat standard host practices see the Official OpenShift Documentation Page for recommended host practices.
+Control plane node sizing The control plane node resource requirements depend on the number of nodes in the cluster. The following control plane node size recommendations are based on the results of control plane density focused testing. The control plane tests create the following objects across the cluster in each of the namespaces depending on the node counts:
+12 image streams
+3 build configurations
+6 builds
+1 deployment with 2 pod replicas mounting two secrets each
+2 deployments with 1 pod replica mounting two secrets
+3 services pointing to the previous deployments
+3 routes pointing to the previous deployments
+10 secrets, 2 of which are mounted by the previous deployments
+10 config maps, 2 of which are mounted by the previous deployments
+Number of worker nodes Cluster load (namespaces) CPU cores Memory (GB) 25
+500
+4
+16
+100
+1000
+8
+32
+250
+4000
+16
+96
+On a cluster with three masters or control plane nodes, the CPU and memory usage will spike up when one of the nodes is stopped, rebooted or fails because the remaining two nodes must handle the load in order to be highly available. This is also expected during upgrades because the masters are cordoned, drained, and rebooted serially to apply the operating system updates, as well as the control plane Operators update. To avoid cascading failures on large and dense clusters, keep the overall resource usage on the master nodes to at most half of all available capacity to handle the resource usage spikes. Increase the CPU and memory on the master nodes accordingly.
+The node sizing varies depending on the number of nodes and object counts in the cluster. It also depends on whether the objects are actively being created on the cluster. During object creation, the control plane is more active in terms of resource usage compared to when the objects are in the running phase.
+If you used an installer-provisioned infrastructure installation method, you cannot modify the control plane node size in a running OpenShift Container Platform 4.5 cluster. Instead, you must estimate your total node count and use the suggested control plane node size during installation.
+The recommendations are based on the data points captured on OpenShift Container Platform clusters with OpenShiftSDN as the network plug-in.
+In OpenShift Container Platform 4.5, half of a CPU core (500 millicore) is now reserved by the system by default compared to OpenShift Container Platform 3.11 and previous versions. The sizes are determined taking that into consideration.
+For more information about sizing and Red Hat standard host practices see the Official OpenShift Documentation Page for recommended host practices.
+Recommended etcd practices For large and dense clusters, etcd can suffer from poor performance if the keyspace grows excessively large and exceeds the space quota. Periodic maintenance of etcd, including defragmentation, must be performed to free up space in the data store. It is highly recommended that you monitor Prometheus for etcd metrics and defragment it when required before etcd raises a cluster-wide alarm that puts the cluster into a maintenance mode, which only accepts key reads and deletes. Some of the key metrics to monitor are etcd_server_quota_backend_bytes which is the current quota limit, etcd_mvcc_db_total_size_in_use_in_bytes which indicates the actual database usage after a history compaction, and etcd_debugging_mvcc_db_total_size_in_bytes which shows the database size including free space waiting for defragmentation. Instructions on defragging etcd can be found in the Defragmenting etcd data section.
+Etcd writes data to disk, so its performance strongly depends on disk performance. Etcd persists proposals on disk. Slow disks and disk activity from other processes might cause long fsync latencies, causing etcd to miss heartbeats, inability to commit new proposals to the disk on time, which can cause request timeouts and temporary leader loss. It is highly recommended to run etcd on machines backed by SSD/NVMe disks with low latency and high throughput.
+Some of the key metrics to monitor on a deployed OpenShift Container Platform cluster are p99 of etcd disk write ahead log duration and the number of etcd leader changes. Use Prometheus to track these metrics. etcd_disk_wal_fsync_duration_seconds_bucket reports the etcd disk fsync duration, etcd_server_leader_changes_seen_total reports the leader changes. To rule out a slow disk and confirm that the disk is reasonably fast, 99th percentile of the etcd_disk_wal_fsync_duration_seconds_bucket should be less than 10ms.
+For more information about sizing and Red Hat standard host practices see the Official OpenShift Documentation Page for recommended host practices.
+`,url:"https://validatedpatterns.io/learn/ocp-cluster-general-sizing/",breadcrumb:"/learn/ocp-cluster-general-sizing/"},"https://validatedpatterns.io/patterns/devsecops/cluster-sizing/":{title:"Cluster Sizing",tags:[],content:`OpenShift Cluster Sizing for the Multicluster DevSecOps Pattern Tested Platforms The Multicluster DevSecOps pattern has been tested in the following Certified Cloud Providers. Due to changes in Advanced Cluster Management 2.5, this pattern does not work, &ldquo;out-of-the-box&rdquo;, with earlier versions of OCP than 4.10. While it&rsquo;s possible that it could work with some changes, we do not recommend using a version less than 4.10.
+| Certified Cloud Providers | 4.10 | 4.11 | 4.x | :&mdash;- | :&mdash;- | :&mdash;- | Amazon Web Services | Tested | Untested | | Google Compute | Untested | Untested | | Microsoft Azure | Untested | Untested |
+Multicluster DevSecOps Pattern Components Here&rsquo;s an inventory of what gets deployed by default the Secure Supply Chain pattern on the Hub OpenShift cluster:
+Name Kind Namespace Description Red Hat Advanced Cluster Management Operator open-cluster-management Advance cluster management Red Hat OpenShift GitOps Operator openshift-operators ArgoCD GitOps Red Hat Advanced Cluster Security Operator stackrox Advanced cluster security, central and secured Red Hat Quay Operator quay-enterprise Secure container registry Red Hat Open Data Foundation Operator openshift-storage Highly available software-defined storage Hashicorp Vault Community version Operator vault Secrets Management The hub can be modified to deploy OpenShift Pipelines if needed. See Development cluster pattern components.
+Multicluster DevSecOps Pattern OpenShift Datacenter HUB Cluster Size The Secure Supply Chain pattern has been tested with a defined set of specifically tested configurations that represent the most common combinations that Red Hat OpenShift Container Platform (OCP) customers are using or deploying for the x86_64 architecture.
+The Hub OpenShift Cluster is made up of the the following on the AWS deployment tested:
+Node Type Number of nodes Cloud Provider Instance Type Control Plane 3 Amazon Web Services m5.xlarge Worker 3 Amazon Web Services m5.4xlarge The Hub OpenShift cluster needs to be a larger than the managed clusters for this demo because it deploys critical pattern infrastructure components like Red Hat Quay which requires Red Hat Open Data Foundation (ODF). The above cluster sizing is close to a minimum size for a Hub cluster. In the next few sections we take some snapshots of the cluster utilization while the Multicluster DevSecOps pattern is running. Keep in mind that resources will have to be added as more images and image versions are added to the Quay registry.
+Hub Cluster utilization Below is a snapshot of the OpenShift cluster utilization while running the Multicluster DevSecOps pattern:
+TBD
+CPU Memory File System Network Pod Count 38 66 GiB 226 MiB 13 MB/s 441 Secure Supply Chain Pattern OpenShift Development (devel) Cluster Size Here&rsquo;s an inventory of what gets deployed by default the Secure Supply Chain pattern on the Development (devel) OpenShift cluster:
+Name Kind Namespace Description Red Hat Advanced Cluster Management agent open-cluster-management Advance cluster management agent only Red Hat OpenShift GitOps Operator openshift-operators ArgoCD GitOps Red Hat Advanced Cluster Security Operator stackrox Advanced cluster security, secured Red Hat OpenShift Pipelines Operator openshift-operators Tekton pipelines for CI Red Hat Quay Bridge Operator openshift-operators Quay registry integration The OpenShift cluster is a standard deployment of 3 control plane nodes and 3 or more worker nodes.
+Node Type Number of nodes Cloud Provider Instance Type Control Plane/Worker 6 Google Cloud n1-standard-8 Control Plane/Worker 6 Amazon Cloud Services m5.2xlarge Control Plane/Worker 6 Microsoft Azure Standard_D8s_v3 Multicluster DevSecOps Pattern OpenShift Production (prod) Cluster Size Here&rsquo;s an inventory of what gets deployed by default the Multicluster DevSecOps pattern on the Production (prod) OpenShift cluster:
+Name Kind Namespace Description Red Hat Advanced Cluster Management agent open-cluster-management Advance cluster management agent only Red Hat OpenShift GitOps Operator openshift-operators ArgoCD GitOps Red Hat Advanced Cluster Security Operator stackrox Advanced cluster security, secured Red Hat Quay Bridge Operator openshift-operators Quay registry integration The OpenShift cluster is a standard datacenter deployment of 3 control plane nodes and 3 or more worker nodes.
+Node Type Number of nodes Cloud Provider Instance Type Control Plane/Worker 6 Google Cloud n1-standard-8 Control Plane/Worker 6 Amazon Cloud Services m5.2xlarge Control Plane/Worker 6 Microsoft Azure Standard_D8s_v3 Managed Datacenter Cluster Utilization GCP
+This is a snapshot of a Google Cloud managed data center cluster running the production Multicluster DevSecOps pattern.
+CPU Memory File System Network Pod Count AWS
+This is a snapshot of a Amazon Web Services managed data center cluster running the production Multicluster DevSecOps pattern.
+CPU Memory File System Network Pod Count Azure
+This is a snapshot of an Azure managed data center cluster running the production Multicluster DevSecOps pattern.
+CPU Memory File System Network Pod Count AWS Instance Types The Multicluster DevSecOps pattern was tested with the highlighted AWS instances in bold. The OpenShift installer will let you know if the instance type meets the minimum requirements for a cluster.
+The message that the openshift installer will give you will be similar to this message
+INFO Credentials loaded from default AWS environment variables FATAL failed to fetch Metadata: failed to load asset &#34;Install Config&#34;: [controlPlane.platform.aws.type: Invalid value: &#34;m4.large&#34;: instance type does not meet minimum resource requirements of 4 vCPUs, controlPlane.platform.aws.type: Invalid value: &#34;m4.large&#34;: instance type does not meet minimum resource requirements of 16384 MiB Memory] Below you can find a list of the AWS instance types that can be used to deploy the Multicluster DevSecOps pattern.
+Instance type Default vCPUs Memory (GiB) Datacenter Factory/Edge 3x3 OCP Cluster 3 Node OCP Cluster m4.xlarge 4 16 N N m4.2xlarge 8 32 Y Y m4.4xlarge 16 64 Y Y m4.10xlarge 40 160 Y Y m4.16xlarge 64 256 Y Y m5.xlarge 4 16 Y N m5.2xlarge 8 32 Y Y m5.4xlarge 16 64 Y Y m5.8xlarge 32 128 Y Y m5.12xlarge 48 192 Y Y m5.16xlarge 64 256 Y Y m5.24xlarge 96 384 Y Y The OpenShift cluster is made of 4 Control Plane nodes and 3 Workers for the Datacenter and the Edge/managed data center cluster are made of 3 Control Plane and 3 Worker nodes. For the node sizes we used the m5.xlarge on AWS and this instance type met the minimum requirements to deploy the Multicluster DevSecOps pattern successfully on the Datacenter hub. On the managed data center cluster we used the m5.xlarge since the minimum cluster was comprised of 3 nodes. .
+To understand better what types of nodes you can use on other Cloud Providers we provide some of the details below.
+Azure Instance Types The Multicluster DevSecOps pattern was also deployed on Azure using the Standard_D8s_v3 VM size. Below is a table of different VM sizes available for Azure. Keep in mind that due to limited access to Azure we only used the Standard_D8s_v3 VM size.
+The OpenShift cluster is made of 3 Control Plane nodes and 3 Workers for the Datacenter cluster.
+The OpenShift cluster is made of 3 Control Plane nodes and 3 or more workers for each of the managed data center clusters.
+Type Sizes Description General purpose B, Dsv3, Dv3, Dasv4, Dav4, DSv2, Dv2, Av2, DC, DCv2, Dv4, Dsv4, Ddv4, Ddsv4 Balanced CPU-to-memory ratio. Ideal for testing and development, small to medium databases, and low to medium traffic web servers. Compute optimized F, Fs, Fsv2, FX High CPU-to-memory ratio. Good for medium traffic web servers, network appliances, batch processes, and application servers. Memory optimized Esv3, Ev3, Easv4, Eav4, Ev4, Esv4, Edv4, Edsv4, Mv2, M, DSv2, Dv2 High memory-to-CPU ratio. Great for relational database servers, medium to large caches, and in-memory analytics. Storage optimized Lsv2 High disk throughput and IO ideal for Big Data, SQL, NoSQL databases, data warehousing and large transactional databases. GPU NC, NCv2, NCv3, NCasT4_v3, ND, NDv2, NV, NVv3, NVv4 Specialized virtual machines targeted for heavy graphic rendering and video editing, as well as model training and inferencing (ND) with deep learning. Available with single or multiple GPUs. High performance compute HB, HBv2, HBv3, HC, H Our fastest and most powerful CPU virtual machines with optional high-throughput network interfaces (RDMA). For more information please refer to the Azure VM Size Page.
+Google Cloud (GCP) Instance Types The Multicluster DevSecOps pattern was also deployed on GCP using the n1-standard-8 VM size. Below is a table of different VM sizes available for GCP. Keep in mind that due to limited access to GCP we only used the n1-standard-8 VM size.
+The OpenShift cluster is made of 3 Control Plane and 3 Workers for the Datacenter cluster.
+The OpenShift cluster is made of 3 Nodes combining Control Plane/Workers for the Edge/managed data center cluster.
+The following table provides VM recommendations for different workloads.
+| General purpose | Workload optimized
+Cost-optimized Balanced Scale-out optimized Memory-optimized Compute-optimized Accelerator-optimized E2 N2, N2D, N1 T2D M2, M1 C2 A2 Day-to-day computing at a lower cost Balanced price/performance across a wide range of VM shapes Best performance/cost for scale-out workloads Ultra high-memory workloads Ultra high performance for compute-intensive workloads Optimized for high performance computing workloads For more information please refer to the GCP VM Size Page.
+`,url:"https://validatedpatterns.io/patterns/devsecops/cluster-sizing/",breadcrumb:"/patterns/devsecops/cluster-sizing/"},"https://validatedpatterns.io/patterns/industrial-edge/cluster-sizing/":{title:"Cluster Sizing",tags:[],content:`OpenShift Cluster Sizing for the Industrial Edge Pattern Tested Platforms The Industrial-Edge pattern has been tested in the following Certified Cloud Providers.
+Certified Cloud Providers 4.8 4.9 4.10 Amazon Web Services :heavy_check_mark: Microsoft Azure :heavy_check_mark: Google Cloud Platform :heavy_check_mark: General OpenShift Minimum Requirements OpenShift 4 has the following minimum requirements for sizing of nodes:
+Minimum 4 vCPU (additional are strongly recommended). Minimum 16 GB RAM (additional memory is strongly recommended, especially if etcd is colocated on masters). Minimum 40 GB hard disk space for the file system containing /var/. Minimum 1 GB hard disk space for the file system containing /usr/local/bin/. There are several applications that comprise the industrial-edge pattern. In addition, the industrial-edge pattern also includes a number of supporting operators that are installed by OpenShift GitOps using ArgoCD.
+Industrial-Edge Pattern Components Here&rsquo;s an inventory of what gets deployed by the Industrial-Edge pattern on the Datacenter/Hub OpenShift cluster:
+Name Kind Namespace Description line-dashboard Application manuela-tst-all Frontend application machine-sensor-1 Application manuela-tst-all Data publisher machine-sensor-2 Application manuela-tst-all Data publisher messaging Application manuela-tst-all Data subscriber mqtt2kafka-integration Application manuela-tst-all Kafka Integration anomaly-detection-predictor-0-anomaly-detection Application manuela-tst-all Anomaly detection application manuela-kafka-cluster-entity-operator Operator manuela-tst-all Kafka Red Hat Advanced Cluster Management Operator open-cluster-management Advance Cluster Management Red Hat Integration - AMQ Broker Operator manuela-tst-all AMQ Broker Red Hat Integration - AMQ Streams Operator manuela-tst-all AMQ Streams Open Data Hub Operator openshift-operators Open Data Hub Red Hat OpenShift GitOps Operator openshift-operators OpenShift GitOps Red Hat Integration - Camel K Operator manuela-tst-all Integration Platform, Kamelet Binding, Kamelet Red Hat OpenShift Pipelines Operator All Namespaces Tekton Config, Pipelines, Triggers, Addons Seldon Operator Operator manuela-tst-all Seldon Deployment Industrial-Edge Pattern OpenShift Datacenter HUB Cluster Size The Industrial-Edge pattern has been tested with a defined set of specifically tested configurations that represent the most common combinations that Red Hat OpenShift Container Platform (OCP) customers are using or deploying for the x86_64 architecture.
+The Datacenter HUB OpenShift Cluster is made up of the the following on the AWS deployment tested:
+Node Type Number of nodes Cloud Provider Instance Type Master 3 Amazon Web Services m5.xlarge Worker 4 Amazon Web Services m5.xlarge The Datacenter HUB OpenShift cluster needs to be a bit bigger than the Factory/Edge clusters because this is where the developers will be running pipelines to build and deploy the Industrial Edge pattern on the cluster. The above cluster sizing is close to a minimum size for a Datacenter HUB cluster. In the next few sections we take some snapshots of the cluster utilization while the Industrial Edge pattern is running. Keep in mind that resources will have to be added as more developers are working building their applications.
+Datacenter Cluster utilization Below is a snapshot of the OpenShift cluster utilization while running the Industrial-Edge pattern:
+CPU Memory File System Network Pod Count 13.84 Used 42.16 available of 56 73.5 GiB 146.3 GiB available of 219.8 GiB 106 GiB 732.9 GiB available of 838.9 GiB 20.65 MBps in 22.84 MBps out 354 pods Industrial-Edge Pattern OpenShift Factory Edge Cluster Size The OpenShift cluster is made of 3 Nodes combining Master/Workers for the Edge/Factory cluster.
+Node Type Number of nodes Cloud Provider Instance Type Master/Worker 3 Google Cloud n1-standard-8 Master/Worker 3 Amazon Cloud Services m5.2xlarge Master/Worker 3 Microsoft Azure Standard_D8s_v3 Factory/Edge Cluster Utilization GCP
+This is a snapshot of a Google Cloud Factory Edge cluster running the production Industrial-Edge pattern.
+CPU Memory File System Network Pod Count 6.55 17.45 available of 24 43.19 GiB usage 45.09 GiB available of 88.28 GiB 48.45 GiB usage 334 GiB available of 382.5 GiB 9.64 MBps in15.79 MBps out 187 pods AWS
+This is a snapshot of a Amazon Web Services Factory Edge cluster running the production Industrial-Edge pattern.
+CPU Memory File System Network Pod Count 5.1 18.9 available of 24 42.91 GiB 49.27 GiB available of 92.18 GiB 51.54 GiB 308 GiB available of 359.5 GiB 9.41 MBps in 10.38 MBps out 194 pods Azure
+This is a snapshot of an Azure Factory Edge cluster running the production Industrial-Edge pattern.
+CPU Memory File System Network Pod Count 7.86 15.65 available of 24 42.76 Gib used 51.15 GiB available of 94.2 GiB 71.29 GiB used 2.93 TiB available of 3 TiB 8.98 MBps in 9.64 MBps out 192 *pods AWS Instance Types The industrial-edge pattern was tested with the highlighted AWS instances in bold. The OpenShift installer will let you know if the instance type meets the minimum requirements for a cluster.
+The message that the openshift installer will give you will be similar to this message
+INFO Credentials loaded from default AWS environment variables FATAL failed to fetch Metadata: failed to load asset &#34;Install Config&#34;: [controlPlane.platform.aws.type: Invalid value: &#34;m4.large&#34;: instance type does not meet minimum resource requirements of 4 vCPUs, controlPlane.platform.aws.type: Invalid value: &#34;m4.large&#34;: instance type does not meet minimum resource requirements of 16384 MiB Memory] Below you can find a list of the AWS instance types that can be used to deploy the industrial-edge pattern.
+Instance type Default vCPUs Memory (GiB) Datacenter Factory/Edge 3x3 OCP Cluster 3 Node OCP Cluster m4.xlarge 4 16 N N m4.2xlarge 8 32 Y Y m4.4xlarge 16 64 Y Y m4.10xlarge 40 160 Y Y m4.16xlarge 64 256 Y Y m5.xlarge 4 16 Y N m5.2xlarge 8 32 Y Y m5.4xlarge 16 64 Y Y m5.8xlarge 32 128 Y Y m5.12xlarge 48 192 Y Y m5.16xlarge 64 256 Y Y m5.24xlarge 96 384 Y Y The OpenShift cluster is made of 4 Masters and 3 Workers for the Datacenter and the Edge/Factory cluster are made of 3 Master/Worker nodes. For the node sizes we used the m5.xlarge on AWS and this instance type met the minimum requirements to deploy the industrial-edge pattern successfully on the Datacenter hub. On the Factory/Edge cluster we used the m5.2xlarge since the minimum cluster was comprised of 3 nodes. .
+To understand better what types of nodes you can use on other Cloud Providers we provide some of the details below.
+Azure Instance Types The industrial-edge pattern was also deployed on Azure using the Standard_D8s_v3 VM size. Below is a table of different VM sizes available for Azure. Keep in mind that due to limited access to Azure we only used the Standard_D8s_v3 VM size.
+The OpenShift cluster is made of 3 Master and 3 Workers for the Datacenter cluster.
+The OpenShift cluster is made of 3 Nodes combining Master/Workers for the Edge/Factory cluster.
+Type Sizes Description General purpose B, Dsv3, Dv3, Dasv4, Dav4, DSv2, Dv2, Av2, DC, DCv2, Dv4, Dsv4, Ddv4, Ddsv4 Balanced CPU-to-memory ratio. Ideal for testing and development, small to medium databases, and low to medium traffic web servers. Compute optimized F, Fs, Fsv2, FX High CPU-to-memory ratio. Good for medium traffic web servers, network appliances, batch processes, and application servers. Memory optimized Esv3, Ev3, Easv4, Eav4, Ev4, Esv4, Edv4, Edsv4, Mv2, M, DSv2, Dv2 High memory-to-CPU ratio. Great for relational database servers, medium to large caches, and in-memory analytics. Storage optimized Lsv2 High disk throughput and IO ideal for Big Data, SQL, NoSQL databases, data warehousing and large transactional databases. GPU NC, NCv2, NCv3, NCasT4_v3, ND, NDv2, NV, NVv3, NVv4 Specialized virtual machines targeted for heavy graphic rendering and video editing, as well as model training and inferencing (ND) with deep learning. Available with single or multiple GPUs. High performance compute HB, HBv2, HBv3, HC, H Our fastest and most powerful CPU virtual machines with optional high-throughput network interfaces (RDMA). For more information please refer to the Azure VM Size Page.
+Google Cloud (GCP) Instance Types The industrial-edge pattern was also deployed on GCP using the n1-standard-8 VM size. Below is a table of different VM sizes available for GCP. Keep in mind that due to limited access to GCP we only used the n1-standard-8 VM size.
+The OpenShift cluster is made of 3 Master and 3 Workers for the Datacenter cluster.
+The OpenShift cluster is made of 3 Nodes combining Master/Workers for the Edge/Factory cluster.
+The following table provides VM recommendations for different workloads.
+| General purpose | Workload optimized
+Cost-optimized Balanced Scale-out optimized Memory-optimized Compute-optimized Accelerator-optimized E2 N2, N2D, N1 T2D M2, M1 C2 A2 Day-to-day computing at a lower cost Balanced price/performance across a wide range of VM shapes Best performance/cost for scale-out workloads Ultra high-memory workloads Ultra high performance for compute-intensive workloads Optimized for high performance computing workloads For more information please refer to the GCP VM Size Page.
+`,url:"https://validatedpatterns.io/patterns/industrial-edge/cluster-sizing/",breadcrumb:"/patterns/industrial-edge/cluster-sizing/"},"https://validatedpatterns.io/patterns/retail/cluster-sizing/":{title:"Cluster Sizing",tags:[],content:`OpenShift Cluster Sizing for the Retail Pattern Tested Platforms The retail pattern has been tested in the following Certified Cloud Providers.
+Certified Cloud Providers 4.10 Amazon Web Services :heavy_check_mark: Microsoft Azure Google Cloud Platform General OpenShift Minimum Requirements OpenShift 4 has the following minimum requirements for sizing of nodes:
+Minimum 4 vCPU (additional are strongly recommended). Minimum 16 GB RAM (additional memory is strongly recommended, especially if etcd is colocated on masters). Minimum 40 GB hard disk space for the file system containing /var/. Minimum 1 GB hard disk space for the file system containing /usr/local/bin/. There are several applications that comprise the retail pattern. In addition, the retail pattern also includes a number of supporting operators that are installed by OpenShift GitOps using ArgoCD.
+Retail Pattern OpenShift Datacenter HUB Cluster Size The retail pattern has been tested with a defined set of specifically tested configurations that represent the most common combinations that Red Hat OpenShift Container Platform (OCP) customers are using or deploying for the x86_64 architecture.
+The Datacenter HUB OpenShift Cluster is made up of the the following on the AWS deployment tested:
+Node Type Number of nodes Cloud Provider Instance Type Master 3 Amazon Web Services m5.xlarge Worker 3 Amazon Web Services m5.xlarge The Datacenter HUB OpenShift cluster needs to be a bit bigger than the Factory/Edge clusters because this is where the developers will be running pipelines to build and deploy the Industrial Edge pattern on the cluster. The above cluster sizing is close to a minimum size for a Datacenter HUB cluster. In the next few sections we take some snapshots of the cluster utilization while the Industrial Edge pattern is running. Keep in mind that resources will have to be added as more developers are working building their applications.
+Retail Pattern OpenShift Store Edge Cluster Size The OpenShift cluster is made of 3 Nodes combining Master/Workers for the Edge/Factory cluster.
+Node Type Number of nodes Cloud Provider Instance Type Master/Worker 3 Google Cloud n1-standard-8 Master/Worker 3 Amazon Cloud Services m5.2xlarge Master/Worker 3 Microsoft Azure Standard_D8s_v3 AWS Instance Types The retail pattern was tested with the highlighted AWS instances in bold. The OpenShift installer will let you know if the instance type meets the minimum requirements for a cluster.
+The message that the openshift installer will give you will be similar to this message
+INFO Credentials loaded from default AWS environment variables FATAL failed to fetch Metadata: failed to load asset &#34;Install Config&#34;: [controlPlane.platform.aws.type: Invalid value: &#34;m4.large&#34;: instance type does not meet minimum resource requirements of 4 vCPUs, controlPlane.platform.aws.type: Invalid value: &#34;m4.large&#34;: instance type does not meet minimum resource requirements of 16384 MiB Memory] Below you can find a list of the AWS instance types that can be used to deploy the retail pattern.
+Instance type Default vCPUs Memory (GiB) Datacenter Factory/Edge 3x3 OCP Cluster 3 Node OCP Cluster m4.xlarge 4 16 N N m4.2xlarge 8 32 Y Y m4.4xlarge 16 64 Y Y m4.10xlarge 40 160 Y Y m4.16xlarge 64 256 Y Y m5.xlarge 4 16 Y N m5.2xlarge 8 32 Y Y m5.4xlarge 16 64 Y Y m5.8xlarge 32 128 Y Y m5.12xlarge 48 192 Y Y m5.16xlarge 64 256 Y Y m5.24xlarge 96 384 Y Y The OpenShift cluster is made of 3 Masters and 3 Workers for the Datacenter and the Edge/Factory cluster are made of 3 Master/Worker nodes. For the node sizes we used the m5.xlarge on AWS and this instance type met the minimum requirements to deploy the retail pattern successfully on the Datacenter hub. On the Factory/Edge cluster we used the m5.2xlarge since the minimum cluster was comprised of 3 nodes. .
+To understand better what types of nodes you can use on other Cloud Providers we provide some of the details below.
+Azure Instance Types The retail pattern was also deployed on Azure using the Standard_D8s_v3 VM size. Below is a table of different VM sizes available for Azure. Keep in mind that due to limited access to Azure we only used the Standard_D8s_v3 VM size.
+The OpenShift cluster is made of 3 Master and 3 Workers for the Datacenter cluster.
+The OpenShift cluster is made of 3 Nodes combining Master/Workers for the Edge/Factory cluster.
+Type Sizes Description General purpose B, Dsv3, Dv3, Dasv4, Dav4, DSv2, Dv2, Av2, DC, DCv2, Dv4, Dsv4, Ddv4, Ddsv4 Balanced CPU-to-memory ratio. Ideal for testing and development, small to medium databases, and low to medium traffic web servers. Compute optimized F, Fs, Fsv2, FX High CPU-to-memory ratio. Good for medium traffic web servers, network appliances, batch processes, and application servers. Memory optimized Esv3, Ev3, Easv4, Eav4, Ev4, Esv4, Edv4, Edsv4, Mv2, M, DSv2, Dv2 High memory-to-CPU ratio. Great for relational database servers, medium to large caches, and in-memory analytics. Storage optimized Lsv2 High disk throughput and IO ideal for Big Data, SQL, NoSQL databases, data warehousing and large transactional databases. GPU NC, NCv2, NCv3, NCasT4_v3, ND, NDv2, NV, NVv3, NVv4 Specialized virtual machines targeted for heavy graphic rendering and video editing, as well as model training and inferencing (ND) with deep learning. Available with single or multiple GPUs. High performance compute HB, HBv2, HBv3, HC, H Our fastest and most powerful CPU virtual machines with optional high-throughput network interfaces (RDMA). For more information please refer to the Azure VM Size Page.
+Google Cloud (GCP) Instance Types The retail pattern was also deployed on GCP using the n1-standard-8 VM size. Below is a table of different VM sizes available for GCP. Keep in mind that due to limited access to GCP we only used the n1-standard-8 VM size.
+The OpenShift cluster is made of 3 Master and 3 Workers for the Datacenter cluster.
+The OpenShift cluster is made of 3 Nodes combining Master/Workers for the Edge/Factory cluster.
+The following table provides VM recommendations for different workloads.
+| General purpose | Workload optimized
+Cost-optimized Balanced Scale-out optimized Memory-optimized Compute-optimized Accelerator-optimized E2 N2, N2D, N1 T2D M2, M1 C2 A2 Day-to-day computing at a lower cost Balanced price/performance across a wide range of VM shapes Best performance/cost for scale-out workloads Ultra high-memory workloads Ultra high performance for compute-intensive workloads Optimized for high performance computing workloads For more information please refer to the GCP VM Size Page.
+`,url:"https://validatedpatterns.io/patterns/retail/cluster-sizing/",breadcrumb:"/patterns/retail/cluster-sizing/"},"https://validatedpatterns.io/patterns/medical-diagnosis-amx/ideas-for-customization/":{title:"Ideas for customization",tags:[],content:`About customizing the pattern Medical Diagnosis pattern One of the major goals of the Validated Patterns development process is to create modular and customizable demos. The Medical Diagnosis pattern is just an example of how AI/ML workloads built for object detection and classification can be run on OpenShift clusters. Consider your workloads for a moment - how would your workload best consume the pattern framework? Do your consumers require on-demand or near real-time responses when using your application? Is your application processing images or data that is protected by either Government Privacy Laws or HIPAA? The Medical Diagnosis pattern can answer the call to either of these requirements by using OpenShift Serverless and OpenShift Data Foundation.
+Understanding different ways to use the Medical Diagnosis pattern The Medical Diagnosis pattern is scanning X-Ray images to determine the probability that a patient might or might not have Pneumonia. Continuing with the medical path, the pattern could be used for other early detection scenarios that use object detection and classification. For example, the pattern could be used to scan C/T images for anomalies in the body such as Sepsis, Cancer, or even benign tumors. Additionally, the pattern could be used for detecting blood clots, some heart disease, and bowel disorders like Crohn’s disease.
+The Transportation Security Agency (TSA) could use the Medical Diagnosis pattern in a way that enhances their existing scanning capabilities to detect with a higher probability restricted items carried on a person or hidden away in a piece of luggage. With Machine Learning Operations (MLOps), the model is constantly training and learning to better detect those items that are dangerous but which are not necessarily metallic, such as a firearm or a knife. The model is also training to dismiss those items that are authorized; ultimately saving passengers from being stopped and searched at security checkpoints.
+Militaries could use images collected from drones, satellites, or other platforms to identify objects and determine with probability what that object is. For example, the model could be trained to determine a type of ship, potentially its country of origin, and other such identifying characteristics.
+Manufacturing companies could use the pattern to inspect finished products as they roll off a production line. An image of the item, including using different types of light, could be analyzed to help expose defects before packaging and distributing. The item could be routed to a defect area.
+These are just a few ideas to help you understand how you could use the Medical Diagnosis pattern as a framework for your application.
+`,url:"https://validatedpatterns.io/patterns/medical-diagnosis-amx/ideas-for-customization/",breadcrumb:"/patterns/medical-diagnosis-amx/ideas-for-customization/"},"https://validatedpatterns.io/patterns/medical-diagnosis/ideas-for-customization/":{title:"Ideas for customization",tags:[],content:`About customizing the pattern Medical Diagnosis pattern One of the major goals of the Validated Patterns development process is to create modular and customizable demos. The Medical Diagnosis pattern is just an example of how AI/ML workloads built for object detection and classification can be run on OpenShift clusters. Consider your workloads for a moment - how would your workload best consume the pattern framework? Do your consumers require on-demand or near real-time responses when using your application? Is your application processing images or data that is protected by either Government Privacy Laws or HIPAA? The Medical Diagnosis pattern can answer the call to either of these requirements by using OpenShift Serverless and OpenShift Data Foundation.
+Understanding different ways to use the Medical Diagnosis pattern The Medical Diagnosis pattern is scanning X-Ray images to determine the probability that a patient might or might not have Pneumonia. Continuing with the medical path, the pattern could be used for other early detection scenarios that use object detection and classification. For example, the pattern could be used to scan C/T images for anomalies in the body such as Sepsis, Cancer, or even benign tumors. Additionally, the pattern could be used for detecting blood clots, some heart disease, and bowel disorders like Crohn’s disease.
+The Transportation Security Agency (TSA) could use the Medical Diagnosis pattern in a way that enhances their existing scanning capabilities to detect with a higher probability restricted items carried on a person or hidden away in a piece of luggage. With Machine Learning Operations (MLOps), the model is constantly training and learning to better detect those items that are dangerous but which are not necessarily metallic, such as a firearm or a knife. The model is also training to dismiss those items that are authorized; ultimately saving passengers from being stopped and searched at security checkpoints.
+Militaries could use images collected from drones, satellites, or other platforms to identify objects and determine with probability what that object is. For example, the model could be trained to determine a type of ship, potentially its country of origin, and other such identifying characteristics.
+Manufacturing companies could use the pattern to inspect finished products as they roll off a production line. An image of the item, including using different types of light, could be analyzed to help expose defects before packaging and distributing. The item could be routed to a defect area.
+These are just a few ideas to help you understand how you could use the Medical Diagnosis pattern as a framework for your application.
+`,url:"https://validatedpatterns.io/patterns/medical-diagnosis/ideas-for-customization/",breadcrumb:"/patterns/medical-diagnosis/ideas-for-customization/"},"https://validatedpatterns.io/patterns/travelops/ideas-for-customization/":{title:"Ideas for customization",tags:[],content:` About customizing the pattern {trvlops-pattern} One of the major goals of the Validated Patterns development process is to create modular, customizable demos. The {trvlops-pattern} is just an example of a pattern that can deploy a Service Mesh and add applications to it using GitOps. When reading these customization ideas really think of them in the context of starting with this pattern and extending it to meet your organizations needs.
+oAuth Configuration
+Create an oAuth provider (HTPasswd, GitHub, MicroSoft)
+Create RBAC (roles, rolebindings) and assign to users
+External prometheus installation
+Integrate openshift-pipelines into the pattern for a full ci/cd experience
+Integrate with Keycloak for AuthN / AuthZ
+Integrate with a real certificate authority like Let’s Encrypt
+`,url:"https://validatedpatterns.io/patterns/travelops/ideas-for-customization/",breadcrumb:"/patterns/travelops/ideas-for-customization/"},"https://validatedpatterns.io/learn/infrastructure/":{title:"Infrastructure",tags:[],content:` Background Each validated pattern has infrastructure requirements. The majority of the validated patterns will run Red Hat OpenShift while some parts will run directly on Red Hat Enterprise Linux or (RHEL), more likely, a version of RHEL called RHEL for Edge. It is expected that consumers of validated patterns already have the infrastructure in place using existing reliable and supported deployment tools. For more information and tools head over to console.redhat.com
+Sizing In this section we provide general minimum sizing requirements for such infrastructure but it is important to review specific requirements for a specific validated pattern. For example, Industrial Edge 2.0 employs AI/Ml technology that requires large machine instances to support the applications deployed on OpenShift at the datacenter.
+`,url:"https://validatedpatterns.io/learn/infrastructure/",breadcrumb:"/learn/infrastructure/"},"https://validatedpatterns.io/patterns/multicloud-gitops-amx-rhoai/mcg-amx-rhoai-managed-cluster/":{title:"Managed cluster sites",tags:[],content:` Attach a managed cluster (edge) to the management hub Understanding Red Hat Advanced Cluster Management requirements By default, Red Hat Advanced Cluster Management (RHACM) manages the clusterGroup applications that are deployed on all clusters. In the value-hub.yaml file, add a managedClusterCgroup for each cluster or group of clusters that you want to manage as one.
+managedClusterGroups: - name: region-one helmOverrides: - name: clusterGroup.isHubCluster value: false clusterSelector: matchLabels: clusterGroup: region-one The above YAML file segment deploys the clusterGroup applications on managed clusters with the label clusterGroup=region-one. Specific subscriptions and Operators, applications and projects for that clusterGroup are then managed in a value-region-one.yaml file. For example:
+namespaces: - config-demo projects: - config-demo applications: config-demo: name: config-demo namespace: config-demo project: config-demo path: charts/all/config-demo #Subscriptions can be added too - multicloud-gitops at present does not require subscriptions on its managed clusters #subscriptions: . # example-subscription # name: example-operator # namespace: example-namespace # channel: example-channel # csv: example-operator.v1.0.0 subscriptions: Ensure that you commit the changes and push them to GitHub so that GitOps can fetch your changes and apply them.
+Deploying a managed cluster by using Red Hat Advanced Cluster Management Prerequisites An OpenShift cluster
+To create an OpenShift cluster, go to the Red Hat Hybrid Cloud console.
+Select Services → Containers → Create cluster.
+Red Hat Advanced Cluster Management (RHACM) web console to join the managed cluster to the management hub
+After RHACM is installed, a message regarding a Web console update is available&#34; might be displayed. Follow the instructions and click the Refresh web console link.
+Procedure In the left navigation panel of web console, click local-cluster. Select All Clusters. The RHACM web console is displayed with Cluster* on the left navigation panel.
+On the Managed clusters tab, click Import cluster.
+On the Import an existing cluster page, enter the cluster name and choose KUBECONFIG as the &#34;import mode&#34;. Add the tag clusterGroup=region-one. Click Import.
+Now that RHACM is no longer deploying the managed cluster applications everywhere, you must indicate that the new cluster has the managed cluster role.
+Optional: Deploying a managed cluster by using cm-cli tool Prerequisites An OpenShift cluster
+To create an OpenShift cluster, go to the Red Hat Hybrid Cloud console.
+Select Services -&gt; Containers -&gt; Create cluster.
+The cm-cli tool
+Procedure Obtain the KUBECONFIG file from the managed cluster.
+Open a shell prompt and login into the management hub cluster by using either of the following methods:
+oc login or
+export KUBECONFIG=~/&lt;path_to_kubeconfig&gt; Run the following command:
+cm attach cluster --cluster &lt;cluster-name&gt; --cluster-kubeconfig &lt;path-to-path_to_kubeconfig&gt; Next steps Designate the new cluster as a managed cluster site
+Optional: Deploying a managed cluster by using the clusteradm tool Prerequisites An OpenShift cluster
+To create an OpenShift cluster, go to the Red Hat Hybrid Cloud console.
+Select Services → Containers → Create cluster.
+The clusteradm tool
+Procedure To deploy an edge cluster, you must to get the token from the management hub cluster. Run the following command on the existing management hub or datacenter cluster:
+clusteradm get token The command generates a token and shows you the command to use on the managed cluster.
+Login to the managed cluster with either of the following methods:
+oc login or
+export KUBECONFIG=~/&lt;path_to_kubeconfig&gt; To request that the managed join the hub cluster, run the following command:
+clusteradm join --hub-token &lt;token_from_clusteradm_get_token_command&gt; &lt;managed_cluster_name&gt; Accept the join request on the hub cluster:
+clusteradm accept --clusters &lt;managed_cluster_name&gt; Next steps Designate the new cluster as a managed cluster site
+Designate the new cluster as a managed cluster site If you use the command line tools such as clusteradm or cm-cli, you must explicitly indicate that the imported cluster is part of a specific clusterGroup. Some examples of clusterGroup are factory, devel, or prod.
+To tag the cluster as clusterGroup=&lt;managed-cluster-group&gt;, complete the following steps.
+Procedure To find the new cluster, run the following command:
+oc get managedcluster.cluster.open-cluster-management.io To apply the label, run the following command:
+oc label managedcluster.cluster.open-cluster-management.io/YOURCLUSTER site=managed-cluster Verification Go to your managed cluster (edge) OpenShift console and check for the open-cluster-management-agent pod being launched. It might take a while for the RHACM agent and agent-addons to launch. After that, the OpenShift GitOps Operator is installed. On successful installation, launch the OpenShift GitOps (ArgoCD) console from the top right of the OpenShift console.
+`,url:"https://validatedpatterns.io/patterns/multicloud-gitops-amx-rhoai/mcg-amx-rhoai-managed-cluster/",breadcrumb:"/patterns/multicloud-gitops-amx-rhoai/mcg-amx-rhoai-managed-cluster/"},"https://validatedpatterns.io/patterns/ansible-edge-gitops-kasten/openshift-virtualization/":{title:"OpenShift Virtualization",tags:[],content:`OpenShift Virtualization Understanding the Edge GitOps VMs Helm Chart The heart of the Edge GitOps VMs helm chart is a template file that was designed with a fair amount of flexibility in mind. Specifically, it allows you to specify:
+One or more &ldquo;groups&rdquo; of VMs (such as &ldquo;kiosk&rdquo; in our example) with an arbitrary number of instances per group Different sizing parameters (cores, threads, memory, disk size) for each group Different SSH keypair credentials for each group Different OS&rsquo;s for each group Different sets of TCP and/or UDP ports open for each group This is to allow you to set up, for example, 4 VMs of one type, 3 VMs of another, and 2 VMs of a third type. This will hopefully abstract the details of VM creation through OpenShift Virtualization and allow you to focus on what kinds and how many of the different sorts of VMs you might need to set up. (Note that AWS&rsquo;s smallest metal node is 72 cores and 192 GB of RAM at initial release, so there is plenty of room for different combinations/configurations.)
+How we got here - Default OpenShift Virtualization templates OpenShift virtualization expects to install virtual machines from image templates by default, and provides a number of OpenShift templates to facilitate this. The default templates are installed in the openshift namespace; the OpenShift console also provides a wizard for creating VMs that use the same templates.
+As of OpenShift Virtualization 4.10.1, the following templates were available on installation:
+$ oc get template NAME DESCRIPTION PARAMETERS OBJECTS 3scale-gateway 3scale&#39;s APIcast is an NGINX based API gateway used to integrate your interna... 17 (8 blank) 3 amq63-basic Application template for JBoss A-MQ brokers. These can be deployed as standal... 11 (4 blank) 6 amq63-persistent An example JBoss A-MQ application. For more information about using this temp... 13 (4 blank) 8 amq63-persistent-ssl An example JBoss A-MQ application. For more information about using this temp... 18 (6 blank) 12 amq63-ssl An example JBoss A-MQ application. For more information about using this temp... 16 (6 blank) 10 apicurito Design beautiful, functional APIs with zero coding, using a visual designer f... 7 (1 blank) 7 cache-service Red Hat Data Grid is an in-memory, distributed key/value store. 8 (1 blank) 4 cakephp-mysql-example An example CakePHP application with a MySQL database. For more information ab... 21 (4 blank) 8 cakephp-mysql-persistent An example CakePHP application with a MySQL database. For more information ab... 22 (4 blank) 9 centos-stream8-desktop-large Template for CentOS Stream 8 VM or newer. A PVC with the CentOS Stream disk i... 4 (2 generated) 1 centos-stream8-desktop-medium Template for CentOS Stream 8 VM or newer. A PVC with the CentOS Stream disk i... 4 (2 generated) 1 centos-stream8-desktop-small Template for CentOS Stream 8 VM or newer. A PVC with the CentOS Stream disk i... 4 (2 generated) 1 centos-stream8-desktop-tiny Template for CentOS Stream 8 VM or newer. A PVC with the CentOS Stream disk i... 4 (2 generated) 1 centos-stream8-server-large Template for CentOS Stream 8 VM or newer. A PVC with the CentOS Stream disk i... 4 (2 generated) 1 centos-stream8-server-medium Template for CentOS Stream 8 VM or newer. A PVC with the CentOS Stream disk i... 4 (2 generated) 1 centos-stream8-server-small Template for CentOS Stream 8 VM or newer. A PVC with the CentOS Stream disk i... 4 (2 generated) 1 centos-stream8-server-tiny Template for CentOS Stream 8 VM or newer. A PVC with the CentOS Stream disk i... 4 (2 generated) 1 centos-stream9-desktop-large Template for CentOS Stream 9 VM or newer. A PVC with the CentOS Stream disk i... 4 (2 generated) 1 centos-stream9-desktop-medium Template for CentOS Stream 9 VM or newer. A PVC with the CentOS Stream disk i... 4 (2 generated) 1 centos-stream9-desktop-small Template for CentOS Stream 9 VM or newer. A PVC with the CentOS Stream disk i... 4 (2 generated) 1 centos-stream9-desktop-tiny Template for CentOS Stream 9 VM or newer. A PVC with the CentOS Stream disk i... 4 (2 generated) 1 centos-stream9-server-large Template for CentOS Stream 9 VM or newer. A PVC with the CentOS Stream disk i... 4 (2 generated) 1 centos-stream9-server-medium Template for CentOS Stream 9 VM or newer. A PVC with the CentOS Stream disk i... 4 (2 generated) 1 centos-stream9-server-small Template for CentOS Stream 9 VM or newer. A PVC with the CentOS Stream disk i... 4 (2 generated) 1 centos-stream9-server-tiny Template for CentOS Stream 9 VM or newer. A PVC with the CentOS Stream disk i... 4 (2 generated) 1 centos7-desktop-large Template for CentOS 7 VM or newer. A PVC with the CentOS disk image must be a... 4 (2 generated) 1 centos7-desktop-medium Template for CentOS 7 VM or newer. A PVC with the CentOS disk image must be a... 4 (2 generated) 1 centos7-desktop-small Template for CentOS 7 VM or newer. A PVC with the CentOS disk image must be a... 4 (2 generated) 1 centos7-desktop-tiny Template for CentOS 7 VM or newer. A PVC with the CentOS disk image must be a... 4 (2 generated) 1 centos7-server-large Template for CentOS 7 VM or newer. A PVC with the CentOS disk image must be a... 4 (2 generated) 1 centos7-server-medium Template for CentOS 7 VM or newer. A PVC with the CentOS disk image must be a... 4 (2 generated) 1 centos7-server-small Template for CentOS 7 VM or newer. A PVC with the CentOS disk image must be a... 4 (2 generated) 1 centos7-server-tiny Template for CentOS 7 VM or newer. A PVC with the CentOS disk image must be a... 4 (2 generated) 1 dancer-mysql-example An example Dancer application with a MySQL database. For more information abo... 18 (5 blank) 8 dancer-mysql-persistent An example Dancer application with a MySQL database. For more information abo... 19 (5 blank) 9 datagrid-service Red Hat Data Grid is an in-memory, distributed key/value store. 7 (1 blank) 4 datavirt64-basic-s2i Application template for JBoss Data Virtualization 6.4 services built using S2I. 20 (6 blank) 6 datavirt64-extensions-support-s2i An example JBoss Data Virtualization application. For more information about... 35 (9 blank) 10 datavirt64-ldap-s2i Application template for JBoss Data Virtualization 6.4 services that configur... 21 (6 blank) 6 datavirt64-secure-s2i An example JBoss Data Virtualization application. For more information about... 51 (22 blank) 8 decisionserver64-amq-s2i An example BRMS decision server A-MQ application. For more information about... 30 (5 blank) 10 decisionserver64-basic-s2i Application template for Red Hat JBoss BRMS 6.4 decision server applications... 17 (5 blank) 5 django-psql-example An example Django application with a PostgreSQL database. For more informatio... 19 (5 blank) 8 django-psql-persistent An example Django application with a PostgreSQL database. For more informatio... 20 (5 blank) 9 eap-xp3-basic-s2i Example of an application based on JBoss EAP XP. For more information about u... 20 (5 blank) 8 eap74-basic-s2i An example JBoss Enterprise Application Platform application. For more inform... 20 (5 blank) 8 eap74-https-s2i An example JBoss Enterprise Application Platform application configured with... 30 (11 blank) 10 eap74-sso-s2i An example JBoss Enterprise Application Platform application Single Sign-On a... 50 (21 blank) 10 fedora-desktop-large Template for Fedora 34 VM or newer. A PVC with the Fedora disk image must be... 4 (2 generated) 1 fedora-desktop-medium Template for Fedora 34 VM or newer. A PVC with the Fedora disk image must be... 4 (2 generated) 1 fedora-desktop-small Template for Fedora 34 VM or newer. A PVC with the Fedora disk image must be... 4 (2 generated) 1 fedora-desktop-tiny Template for Fedora 34 VM or newer. A PVC with the Fedora disk image must be... 4 (2 generated) 1 fedora-highperformance-large Template for Fedora 34 VM or newer. A PVC with the Fedora disk image must be... 4 (2 generated) 1 fedora-highperformance-medium Template for Fedora 34 VM or newer. A PVC with the Fedora disk image must be... 4 (2 generated) 1 fedora-highperformance-small Template for Fedora 34 VM or newer. A PVC with the Fedora disk image must be... 4 (2 generated) 1 fedora-highperformance-tiny Template for Fedora 34 VM or newer. A PVC with the Fedora disk image must be... 4 (2 generated) 1 fedora-server-large Template for Fedora 34 VM or newer. A PVC with the Fedora disk image must be... 4 (2 generated) 1 fedora-server-medium Template for Fedora 34 VM or newer. A PVC with the Fedora disk image must be... 4 (2 generated) 1 fedora-server-small Template for Fedora 34 VM or newer. A PVC with the Fedora disk image must be... 4 (2 generated) 1 fedora-server-tiny Template for Fedora 34 VM or newer. A PVC with the Fedora disk image must be... 4 (2 generated) 1 fuse710-console The Red Hat Fuse Console eases the discovery and management of Fuse applicati... 8 (1 blank) 5 httpd-example An example Apache HTTP Server (httpd) application that serves static content.... 9 (3 blank) 5 jenkins-ephemeral Jenkins service, without persistent storage.... 11 (all set) 7 jenkins-ephemeral-monitored Jenkins service, without persistent storage. ... 12 (all set) 8 jenkins-persistent Jenkins service, with persistent storage.... 13 (all set) 8 jenkins-persistent-monitored Jenkins service, with persistent storage. ... 14 (all set) 9 jws31-tomcat7-basic-s2i Application template for JWS applications built using S2I. 12 (3 blank) 5 jws31-tomcat7-https-s2i An example JBoss Web Server application configured for use with https. For mo... 17 (5 blank) 7 jws31-tomcat8-basic-s2i An example JBoss Web Server application. For more information about using thi... 12 (3 blank) 5 jws31-tomcat8-https-s2i An example JBoss Web Server application. For more information about using thi... 17 (5 blank) 7 jws56-openjdk11-tomcat9-ubi8-basic-s2i An example JBoss Web Server application. For more information about using thi... 10 (3 blank) 5 jws56-openjdk11-tomcat9-ubi8-https-s2i An example JBoss Web Server application. For more information about using thi... 15 (5 blank) 7 jws56-openjdk8-tomcat9-ubi8-basic-s2i An example JBoss Web Server application. For more information about using thi... 10 (3 blank) 5 jws56-openjdk8-tomcat9-ubi8-https-s2i An example JBoss Web Server application. For more information about using thi... 15 (5 blank) 7 mariadb-ephemeral MariaDB database service, without persistent storage. For more information ab... 8 (3 generated) 3 mariadb-persistent MariaDB database service, with persistent storage. For more information about... 9 (3 generated) 4 mysql-ephemeral MySQL database service, without persistent storage. For more information abou... 8 (3 generated) 3 mysql-persistent MySQL database service, with persistent storage. For more information about u... 9 (3 generated) 4 nginx-example An example Nginx HTTP server and a reverse proxy (nginx) application that ser... 10 (3 blank) 5 nodejs-postgresql-example An example Node.js application with a PostgreSQL database. For more informati... 18 (4 blank) 8 nodejs-postgresql-persistent An example Node.js application with a PostgreSQL database. For more informati... 19 (4 blank) 9 openjdk-web-basic-s2i An example Java application using OpenJDK. For more information about using t... 9 (1 blank) 5 postgresql-ephemeral PostgreSQL database service, without persistent storage. For more information... 7 (2 generated) 3 postgresql-persistent PostgreSQL database service, with persistent storage. For more information ab... 8 (2 generated) 4 processserver64-amq-mysql-persistent-s2i An example BPM Suite application with A-MQ and a MySQL database. For more inf... 49 (13 blank) 14 processserver64-amq-mysql-s2i An example BPM Suite application with A-MQ and a MySQL database. For more inf... 47 (13 blank) 12 processserver64-amq-postgresql-persistent-s2i An example BPM Suite application with A-MQ and a PostgreSQL database. For mor... 46 (10 blank) 14 processserver64-amq-postgresql-s2i An example BPM Suite application with A-MQ and a PostgreSQL database. For mor... 44 (10 blank) 12 processserver64-basic-s2i An example BPM Suite application. For more information about using this templ... 17 (5 blank) 5 processserver64-externaldb-s2i An example BPM Suite application with a external database. For more informati... 47 (22 blank) 7 processserver64-mysql-persistent-s2i An example BPM Suite application with a MySQL database. For more information... 40 (14 blank) 10 processserver64-mysql-s2i An example BPM Suite application with a MySQL database. For more information... 39 (14 blank) 9 processserver64-postgresql-persistent-s2i An example BPM Suite application with a PostgreSQL database. For more informa... 37 (11 blank) 10 rails-pgsql-persistent An example Rails application with a PostgreSQL database. For more information... 21 (4 blank) 9 rails-postgresql-example An example Rails application with a PostgreSQL database. For more information... 20 (4 blank) 8 redis-ephemeral Redis in-memory data structure store, without persistent storage. For more in... 5 (1 generated) 3 redis-persistent Redis in-memory data structure store, with persistent storage. For more infor... 6 (1 generated) 4 rhdm711-authoring Application template for a non-HA persistent authoring environment, for Red H... 76 (46 blank) 11 rhdm711-authoring-ha Application template for a HA persistent authoring environment, for Red Hat D... 92 (47 blank) 17 rhdm711-kieserver Application template for a managed KIE Server, for Red Hat Decision Manager 7... 61 (42 blank) 6 rhdm711-prod-immutable-kieserver Application template for an immutable KIE Server in a production environment,... 66 (45 blank) 8 rhdm711-prod-immutable-kieserver-amq Application template for an immutable KIE Server in a production environment... 80 (54 blank) 20 rhdm711-trial-ephemeral Application template for an ephemeral authoring and testing environment, for... 63 (40 blank) 8 rhel6-desktop-large Template for Red Hat Enterprise Linux 6 VM or newer. A PVC with the RHEL disk... 4 (2 generated) 1 rhel6-desktop-medium Template for Red Hat Enterprise Linux 6 VM or newer. A PVC with the RHEL disk... 4 (2 generated) 1 rhel6-desktop-small Template for Red Hat Enterprise Linux 6 VM or newer. A PVC with the RHEL disk... 4 (2 generated) 1 rhel6-desktop-tiny Template for Red Hat Enterprise Linux 6 VM or newer. A PVC with the RHEL disk... 4 (2 generated) 1 rhel6-server-large Template for Red Hat Enterprise Linux 6 VM or newer. A PVC with the RHEL disk... 4 (2 generated) 1 rhel6-server-medium Template for Red Hat Enterprise Linux 6 VM or newer. A PVC with the RHEL disk... 4 (2 generated) 1 rhel6-server-small Template for Red Hat Enterprise Linux 6 VM or newer. A PVC with the RHEL disk... 4 (2 generated) 1 rhel6-server-tiny Template for Red Hat Enterprise Linux 6 VM or newer. A PVC with the RHEL disk... 4 (2 generated) 1 rhel7-desktop-large Template for Red Hat Enterprise Linux 7 VM or newer. A PVC with the RHEL disk... 4 (2 generated) 1 rhel7-desktop-medium Template for Red Hat Enterprise Linux 7 VM or newer. A PVC with the RHEL disk... 4 (2 generated) 1 rhel7-desktop-small Template for Red Hat Enterprise Linux 7 VM or newer. A PVC with the RHEL disk... 4 (2 generated) 1 rhel7-desktop-tiny Template for Red Hat Enterprise Linux 7 VM or newer. A PVC with the RHEL disk... 4 (2 generated) 1 rhel7-highperformance-large Template for Red Hat Enterprise Linux 7 VM or newer. A PVC with the RHEL disk... 4 (2 generated) 1 rhel7-highperformance-medium Template for Red Hat Enterprise Linux 7 VM or newer. A PVC with the RHEL disk... 4 (2 generated) 1 rhel7-highperformance-small Template for Red Hat Enterprise Linux 7 VM or newer. A PVC with the RHEL disk... 4 (2 generated) 1 rhel7-highperformance-tiny Template for Red Hat Enterprise Linux 7 VM or newer. A PVC with the RHEL disk... 4 (2 generated) 1 rhel7-server-large Template for Red Hat Enterprise Linux 7 VM or newer. A PVC with the RHEL disk... 4 (2 generated) 1 rhel7-server-medium Template for Red Hat Enterprise Linux 7 VM or newer. A PVC with the RHEL disk... 4 (2 generated) 1 rhel7-server-small Template for Red Hat Enterprise Linux 7 VM or newer. A PVC with the RHEL disk... 4 (2 generated) 1 rhel7-server-tiny Template for Red Hat Enterprise Linux 7 VM or newer. A PVC with the RHEL disk... 4 (2 generated) 1 rhel8-desktop-large Template for Red Hat Enterprise Linux 8 VM or newer. A PVC with the RHEL disk... 4 (2 generated) 1 rhel8-desktop-medium Template for Red Hat Enterprise Linux 8 VM or newer. A PVC with the RHEL disk... 4 (2 generated) 1 rhel8-desktop-small Template for Red Hat Enterprise Linux 8 VM or newer. A PVC with the RHEL disk... 4 (2 generated) 1 rhel8-desktop-tiny Template for Red Hat Enterprise Linux 8 VM or newer. A PVC with the RHEL disk... 4 (2 generated) 1 rhel8-highperformance-large Template for Red Hat Enterprise Linux 8 VM or newer. A PVC with the RHEL disk... 4 (2 generated) 1 rhel8-highperformance-medium Template for Red Hat Enterprise Linux 8 VM or newer. A PVC with the RHEL disk... 4 (2 generated) 1 rhel8-highperformance-small Template for Red Hat Enterprise Linux 8 VM or newer. A PVC with the RHEL disk... 4 (2 generated) 1 rhel8-highperformance-tiny Template for Red Hat Enterprise Linux 8 VM or newer. A PVC with the RHEL disk... 4 (2 generated) 1 rhel8-server-large Template for Red Hat Enterprise Linux 8 VM or newer. A PVC with the RHEL disk... 4 (2 generated) 1 rhel8-server-medium Template for Red Hat Enterprise Linux 8 VM or newer. A PVC with the RHEL disk... 4 (2 generated) 1 rhel8-server-small Template for Red Hat Enterprise Linux 8 VM or newer. A PVC with the RHEL disk... 4 (2 generated) 1 rhel8-server-tiny Template for Red Hat Enterprise Linux 8 VM or newer. A PVC with the RHEL disk... 4 (2 generated) 1 rhel9-desktop-large Template for Red Hat Enterprise Linux 9 VM or newer. A PVC with the RHEL disk... 4 (2 generated) 1 rhel9-desktop-medium Template for Red Hat Enterprise Linux 9 VM or newer. A PVC with the RHEL disk... 4 (2 generated) 1 rhel9-desktop-small Template for Red Hat Enterprise Linux 9 VM or newer. A PVC with the RHEL disk... 4 (2 generated) 1 rhel9-desktop-tiny Template for Red Hat Enterprise Linux 9 VM or newer. A PVC with the RHEL disk... 4 (2 generated) 1 rhel9-highperformance-large Template for Red Hat Enterprise Linux 9 VM or newer. A PVC with the RHEL disk... 4 (2 generated) 1 rhel9-highperformance-medium Template for Red Hat Enterprise Linux 9 VM or newer. A PVC with the RHEL disk... 4 (2 generated) 1 rhel9-highperformance-small Template for Red Hat Enterprise Linux 9 VM or newer. A PVC with the RHEL disk... 4 (2 generated) 1 rhel9-highperformance-tiny Template for Red Hat Enterprise Linux 9 VM or newer. A PVC with the RHEL disk... 4 (2 generated) 1 rhel9-server-large Template for Red Hat Enterprise Linux 9 VM or newer. A PVC with the RHEL disk... 4 (2 generated) 1 rhel9-server-medium Template for Red Hat Enterprise Linux 9 VM or newer. A PVC with the RHEL disk... 4 (2 generated) 1 rhel9-server-small Template for Red Hat Enterprise Linux 9 VM or newer. A PVC with the RHEL disk... 4 (2 generated) 1 rhel9-server-tiny Template for Red Hat Enterprise Linux 9 VM or newer. A PVC with the RHEL disk... 4 (2 generated) 1 rhpam711-authoring Application template for a non-HA persistent authoring environment, for Red H... 80 (46 blank) 12 rhpam711-authoring-ha Application template for a HA persistent authoring environment, for Red Hat P... 101 (47 blank) 20 rhpam711-kieserver-externaldb Application template for a managed KIE Server with an external database, for... 83 (59 blank) 8 rhpam711-kieserver-mysql Application template for a managed KIE Server with a MySQL database, for Red... 70 (42 blank) 9 rhpam711-kieserver-postgresql Application template for a managed KIE Server with a PostgreSQL database, for... 71 (42 blank) 9 rhpam711-managed Application template for a managed HA production runtime environment, for Red... 87 (46 blank) 14 rhpam711-prod Application template for a managed HA production runtime environment, for Red... 102 (55 blank) 28 rhpam711-prod-immutable-kieserver Application template for an immutable KIE Server in a production environment,... 76 (45 blank) 11 rhpam711-prod-immutable-kieserver-amq Application template for an immutable KIE Server in a production environment... 97 (58 blank) 23 rhpam711-prod-immutable-monitor Application template for a router and monitoring console in a production envi... 66 (44 blank) 14 rhpam711-trial-ephemeral Application template for an ephemeral authoring and testing environment, for... 63 (40 blank) 8 s2i-fuse710-spring-boot-2-camel Spring Boot 2 and Camel QuickStart. This example demonstrates how you can use... 18 (3 blank) 3 s2i-fuse710-spring-boot-2-camel-rest-3scale Spring Boot 2, Camel REST DSL and 3Scale QuickStart. This example demonstrate... 19 (3 blank) 5 s2i-fuse710-spring-boot-2-camel-xml Spring Boot 2 and Camel Xml QuickStart. This example demonstrates how you can... 18 (3 blank) 3 sso72-https An example RH-SSO 7 application. For more information about using this templa... 26 (15 blank) 6 sso72-mysql An example RH-SSO 7 application with a MySQL database. For more information a... 36 (20 blank) 8 sso72-mysql-persistent An example RH-SSO 7 application with a MySQL database. For more information a... 37 (20 blank) 9 sso72-postgresql An example RH-SSO 7 application with a PostgreSQL database. For more informat... 33 (17 blank) 8 sso72-postgresql-persistent An example RH-SSO 7 application with a PostgreSQL database. For more informat... 34 (17 blank) 9 sso73-https An example application based on RH-SSO 7.3 image. For more information about... 27 (16 blank) 6 sso73-mysql An example application based on RH-SSO 7.3 image. For more information about... 37 (21 blank) 8 sso73-mysql-persistent An example application based on RH-SSO 7.3 image. For more information about... 38 (21 blank) 9 sso73-ocp4-x509-https An example application based on RH-SSO 7.3 image. For more information about... 13 (7 blank) 5 sso73-ocp4-x509-mysql-persistent An example application based on RH-SSO 7.3 image. For more information about... 24 (12 blank) 8 sso73-ocp4-x509-postgresql-persistent An example application based on RH-SSO 7.3 image. For more information about... 21 (9 blank) 8 sso73-postgresql An example application based on RH-SSO 7.3 image. For more information about... 34 (18 blank) 8 sso73-postgresql-persistent An example application based on RH-SSO 7.3 image. For more information about... 35 (18 blank) 9 sso74-https An example application based on RH-SSO 7.4 on OpenJDK image. For more informa... 27 (16 blank) 6 sso74-ocp4-x509-https An example application based on RH-SSO 7.4 on OpenJDK image. For more informa... 13 (7 blank) 5 sso74-ocp4-x509-postgresql-persistent An example application based on RH-SSO 7.4 on OpenJDK image. For more informa... 21 (9 blank) 8 sso74-postgresql An example application based on RH-SSO 7.4 on OpenJDK image. For more informa... 34 (18 blank) 8 sso74-postgresql-persistent An example application based on RH-SSO 7.4 on OpenJDK image. For more informa... 35 (18 blank) 9 sso75-https An example application based on RH-SSO 7.5 on OpenJDK image. For more informa... 27 (16 blank) 6 sso75-ocp4-x509-https An example application based on RH-SSO 7.5 on OpenJDK image. For more informa... 13 (7 blank) 5 sso75-ocp4-x509-postgresql-persistent An example application based on RH-SSO 7.5 on OpenJDK image. For more informa... 21 (9 blank) 8 sso75-postgresql An example application based on RH-SSO 7.5 on OpenJDK image. For more informa... 34 (18 blank) 8 sso75-postgresql-persistent An example application based on RH-SSO 7.5 on OpenJDK image. For more informa... 35 (18 blank) 9 windows10-desktop-large Template for Microsoft Windows 10 VM. A PVC with the Windows disk image must... 3 (1 generated) 1 windows10-desktop-medium Template for Microsoft Windows 10 VM. A PVC with the Windows disk image must... 3 (1 generated) 1 windows10-highperformance-large Template for Microsoft Windows 10 VM. A PVC with the Windows disk image must... 3 (1 generated) 1 windows10-highperformance-medium Template for Microsoft Windows 10 VM. A PVC with the Windows disk image must... 3 (1 generated) 1 windows2k12r2-highperformance-large Template for Microsoft Windows Server 2012 R2 VM. A PVC with the Windows disk... 3 (1 generated) 1 windows2k12r2-highperformance-medium Template for Microsoft Windows Server 2012 R2 VM. A PVC with the Windows disk... 3 (1 generated) 1 windows2k12r2-server-large Template for Microsoft Windows Server 2012 R2 VM. A PVC with the Windows disk... 3 (1 generated) 1 windows2k12r2-server-medium Template for Microsoft Windows Server 2012 R2 VM. A PVC with the Windows disk... 3 (1 generated) 1 windows2k16-highperformance-large Template for Microsoft Windows Server 2016 VM. A PVC with the Windows disk im... 3 (1 generated) 1 windows2k16-highperformance-medium Template for Microsoft Windows Server 2016 VM. A PVC with the Windows disk im... 3 (1 generated) 1 windows2k16-server-large Template for Microsoft Windows Server 2016 VM. A PVC with the Windows disk im... 3 (1 generated) 1 windows2k16-server-medium Template for Microsoft Windows Server 2016 VM. A PVC with the Windows disk im... 3 (1 generated) 1 windows2k19-highperformance-large Template for Microsoft Windows Server 2019 VM. A PVC with the Windows disk im... 3 (1 generated) 1 windows2k19-highperformance-medium Template for Microsoft Windows Server 2019 VM. A PVC with the Windows disk im... 3 (1 generated) 1 windows2k19-server-large Template for Microsoft Windows Server 2019 VM. A PVC with the Windows disk im... 3 (1 generated) 1 windows2k19-server-medium Template for Microsoft Windows Server 2019 VM. A PVC with the Windows disk im... 3 (1 generated) 1 Additionally, you may copy and customize these templates if you wish. The template file is an example of a customized template that was used to help develop this pattern.
+Creating a VM from the Console via Template These templates can be run through the OpenShift Console from the Virtualization tab. Note the &ldquo;Create VM&rdquo; buttons on the right side of this picture:
+Clicking on the &ldquo;Create VM&rdquo; button will bring up a wizard that looks like this:
+Accepting the defaults from this wizard will give a success screen:
+Until it is deleted, you can monitor the machine&rsquo;s lifecycle from the VirtualMachines tab:
+This is a great way to gain familiarity with how the system works, but we might possibly want an interface we can use more programmatically.
+Creating a VM from the command line via oc process This is a useful way to understand what kinds of objects OpenShift Virtualization creates and manages:
+$ oc process -n openshift rhel8-desktop-medium | oc apply -f - virtualmachine.kubevirt.io/rhel8-q63yuvxpjdvy18l7 created You could also use the &ldquo;Create VM Wizard&rdquo; in the OpenShift console.
+Another option - capturing template output and converting it into a Helm Chart See details here.
+Components of the virtual-machines template Setup - the mechanism for creating identifiers declaratively The first part of the template file sets up some variables that we will use later as the template is expanded. We use a sequential numbering scheme for VM name creation because that is an easy way to make each item in the set declarative - it ensures that if you ask for 5 VMs of a particular type, they will have predictable names, and if one is deleted, it will be replaced by a VM with the same name.
+We use explicit &ldquo;range&rdquo; variables for the Go templating. This is because the implicit range variable is easily &ldquo;trampled&rdquo;, and we have at least two different dimensions to iterate on - vm &ldquo;role&rdquo; and &ldquo;index&rdquo; within that role.
+The External Secret - SSH pubkey The first item we define as part of this structure is an external secret to hold an SSH pubkey. This pubkey will be mounted in the VM under an unprivileged user&rsquo;s home directory - and generally that unprivileged user is expected to be able to sudo root without password. By default, RHEL images are configured to only allow SSH access via pubkey. In this pattern, the private key and public key for the SSH connections are loaded into both Vault (which we inherited from previous patterns) and Ansible Automation Platform.
+Since the keys are defined per VM &ldquo;group&rdquo;, it is possible and expected that you could have different keypairs for different groups of VMs. Nothing would prevent you from using the same keypair for all machines if you have different groups, though.
+While the pubkey is not truly a &ldquo;secret&rdquo;, the availability of the External Secrets Operator made for a nice opportunity to allow for variance in configuration without necessarily requiring local customization of the pattern. The OpenShift Virtualization model has no way of knowing that multiple servers may have the same SSH credentials, and in fact cannot depend on this. So it creates a pubkey object by default for each VM, and we imitate this behavior in the pattern.
+The VirtualMachine definition The VirtualMachine definition is the biggest part of the template. All of it is derived from customization of the default templates that OpenShift Virtualization installs in the openshift namespace - especially most of the labels and annotations, with the following exceptions:
+labels app This is set to $identifier to match a general pattern with other applications.
+edge-gitops-role This is set explicitly and used elsewhere in this pattern to help identify resources by role. The intention is to be able to use the edge-gitops-role as a selector for targeting various kind of queries, including (especially) Ansible inventories. Though please note - because of the way Kubernetes (and OpenShift) work, when you connect to a VM with Ansible you are connecting to the Service object directly, not to the VM. (Another way to look at it is that the Service object is providing network abstraction over the VM object.)
+Other resources in the rest of the VirtualMachine definition are copied from the default template, with appropriate Helm variables included.
+Initial user access Note that the initial user (default: cloud-user) and initial password are customizable via values overrides. The kiosk type shows an example of how to either use a user/password specific to the type or a default for the chart using the coalesce function.
+The Service definition The Service definition is potentially complex. The purpose of this Service object is to expose all of the needed TCP and UDP network ports within the cluster. (Providing access to them from outside the cluster would require Route or Ingress objects, and would have some significant security implications; access to these entities from outside the cluster is not the focus of this pattern, so we do not provide it at this time.)
+A given VM may expose one port (for Ansible access, you need at least TCP/22), or it may expose many ports. You are free to define a service per port if you like, but it seems more convenient to define them all as a single service.
+One aspect of the templating you may find interesting is the use of the toPrettyJson filter in Go. Since YAML is a proper superset of JSON, this is a neat trick that allows to include a nested data structure without having to worry about how to indent it. (As toPrettyJson uses the square bracket ([]) and curly bracket ({}) notation for arrays and hashes, YAML can interpret it without worrying about its indentation.
+Accessing the VMs There are three mechanisms for access to these VMs:
+Ansible - keypair authentication The ssh keypairs from your values-secret.yaml are loaded into both Vault and AAP for use later. The pattern currently defines one such keypair, kiosk-ssh, but could support more, such as iot-ssh, gateway-ssh, etc. more details on how to expand on this pattern are described below.
+AAP only needs the private key and the username as a machine credential. The public key is not truly a secret, but it seemed interesting and useful to use the external secret operator to associate the public key with VM instances this way and prevent having to diverge from the upstream pattern to include local ssh pubkey specifications.
+Note that the default SSH setting for RHEL does not allow password-based logins via SSH, and it&rsquo;s at the very least inconvenient to copy the SSH private key into a VM inside the cluster, so the typical way the keypair will be used is through Ansible.
+Virtual Machine Console Access via OpenShift Console Navigate to Virtualization -&gt; VirtualMachines and make sure Project: All Projects or edge-gitops-vms is selected:
+Click on the &ldquo;three dots&rdquo; menu on the right, which will open a dialog like the following:
+Note: In OpenShift Virtualization 4.11, the &ldquo;Open Console&rdquo; option appears when you click on the virtual machine name in openshift console. The dialog looks like this:
+The virtual machine console view will either show a standard RHEL console login screen, or if the demo is working as designed, it will show the Ignition application running in kiosk mode. If the console shows a standard RHEL login, it can be accessed using the the initial user name (cloud-user by default) and password (which is what is specified in the Helm chart Values as either the password specific to that machine group, the default cloudInit, or a hardcoded default which can be seen in the template here. On a VM created through the wizard or via oc process from a template, the password will be set on the VirtualMachine object in the volumes section.
+Initial User login (cloud-user) In general, and before the VMs have been configured by the Ansible Jobs, you can log in to the VMs on the console using the user and password you specified in the Helm chart, or else you can look at the VirtualMachine object and see what the username and password setting are. The pattern, by design, replaces the typical console view with Firefox running in kiosk mode. But this mechanism can still be used if you change the console from &ldquo;VNC Console&rdquo; to &ldquo;Serial Console&rdquo;.
+The &ldquo;extra&rdquo; VM Template Also included in the edge-gitops-vms chart is a separate template that will allow the creation of VMs with similar (though not identical characteristics) to the ones defined in the chart.
+The rhel8-kiosk-with-svc template is preserved as an intermediate step to creating your own VM types, to see how the pipeline from default VM template -&gt; customized template -&gt; Helm-variable chart can work.
+Next Steps Help &amp; Feedback Report Bugs `,url:"https://validatedpatterns.io/patterns/ansible-edge-gitops-kasten/openshift-virtualization/",breadcrumb:"/patterns/ansible-edge-gitops-kasten/openshift-virtualization/"},"https://validatedpatterns.io/patterns/ansible-edge-gitops/openshift-virtualization/":{title:"OpenShift Virtualization",tags:[],content:`OpenShift Virtualization Understanding the Edge GitOps VMs Helm Chart The heart of the Edge GitOps VMs helm chart is a template file that was designed with a fair amount of flexibility in mind. Specifically, it allows you to specify:
+One or more &ldquo;groups&rdquo; of VMs (such as &ldquo;kiosk&rdquo; in our example) with an arbitrary number of instances per group Different sizing parameters (cores, threads, memory, disk size) for each group Different SSH keypair credentials for each group Different OS&rsquo;s for each group Different sets of TCP and/or UDP ports open for each group This is to allow you to set up, for example, 4 VMs of one type, 3 VMs of another, and 2 VMs of a third type. This will hopefully abstract the details of VM creation through OpenShift Virtualization and allow you to focus on what kinds and how many of the different sorts of VMs you might need to set up. (Note that AWS&rsquo;s smallest metal node is 72 cores and 192 GB of RAM at initial release, so there is plenty of room for different combinations/configurations.)
+How we got here - Default OpenShift Virtualization templates OpenShift virtualization expects to install virtual machines from image templates by default, and provides a number of OpenShift templates to facilitate this. The default templates are installed in the openshift namespace; the OpenShift console also provides a wizard for creating VMs that use the same templates.
+As of OpenShift Virtualization 4.10.1, the following templates were available on installation:
+$ oc get template NAME DESCRIPTION PARAMETERS OBJECTS 3scale-gateway 3scale&#39;s APIcast is an NGINX based API gateway used to integrate your interna... 17 (8 blank) 3 amq63-basic Application template for JBoss A-MQ brokers. These can be deployed as standal... 11 (4 blank) 6 amq63-persistent An example JBoss A-MQ application. For more information about using this temp... 13 (4 blank) 8 amq63-persistent-ssl An example JBoss A-MQ application. For more information about using this temp... 18 (6 blank) 12 amq63-ssl An example JBoss A-MQ application. For more information about using this temp... 16 (6 blank) 10 apicurito Design beautiful, functional APIs with zero coding, using a visual designer f... 7 (1 blank) 7 cache-service Red Hat Data Grid is an in-memory, distributed key/value store. 8 (1 blank) 4 cakephp-mysql-example An example CakePHP application with a MySQL database. For more information ab... 21 (4 blank) 8 cakephp-mysql-persistent An example CakePHP application with a MySQL database. For more information ab... 22 (4 blank) 9 centos-stream8-desktop-large Template for CentOS Stream 8 VM or newer. A PVC with the CentOS Stream disk i... 4 (2 generated) 1 centos-stream8-desktop-medium Template for CentOS Stream 8 VM or newer. A PVC with the CentOS Stream disk i... 4 (2 generated) 1 centos-stream8-desktop-small Template for CentOS Stream 8 VM or newer. A PVC with the CentOS Stream disk i... 4 (2 generated) 1 centos-stream8-desktop-tiny Template for CentOS Stream 8 VM or newer. A PVC with the CentOS Stream disk i... 4 (2 generated) 1 centos-stream8-server-large Template for CentOS Stream 8 VM or newer. A PVC with the CentOS Stream disk i... 4 (2 generated) 1 centos-stream8-server-medium Template for CentOS Stream 8 VM or newer. A PVC with the CentOS Stream disk i... 4 (2 generated) 1 centos-stream8-server-small Template for CentOS Stream 8 VM or newer. A PVC with the CentOS Stream disk i... 4 (2 generated) 1 centos-stream8-server-tiny Template for CentOS Stream 8 VM or newer. A PVC with the CentOS Stream disk i... 4 (2 generated) 1 centos-stream9-desktop-large Template for CentOS Stream 9 VM or newer. A PVC with the CentOS Stream disk i... 4 (2 generated) 1 centos-stream9-desktop-medium Template for CentOS Stream 9 VM or newer. A PVC with the CentOS Stream disk i... 4 (2 generated) 1 centos-stream9-desktop-small Template for CentOS Stream 9 VM or newer. A PVC with the CentOS Stream disk i... 4 (2 generated) 1 centos-stream9-desktop-tiny Template for CentOS Stream 9 VM or newer. A PVC with the CentOS Stream disk i... 4 (2 generated) 1 centos-stream9-server-large Template for CentOS Stream 9 VM or newer. A PVC with the CentOS Stream disk i... 4 (2 generated) 1 centos-stream9-server-medium Template for CentOS Stream 9 VM or newer. A PVC with the CentOS Stream disk i... 4 (2 generated) 1 centos-stream9-server-small Template for CentOS Stream 9 VM or newer. A PVC with the CentOS Stream disk i... 4 (2 generated) 1 centos-stream9-server-tiny Template for CentOS Stream 9 VM or newer. A PVC with the CentOS Stream disk i... 4 (2 generated) 1 centos7-desktop-large Template for CentOS 7 VM or newer. A PVC with the CentOS disk image must be a... 4 (2 generated) 1 centos7-desktop-medium Template for CentOS 7 VM or newer. A PVC with the CentOS disk image must be a... 4 (2 generated) 1 centos7-desktop-small Template for CentOS 7 VM or newer. A PVC with the CentOS disk image must be a... 4 (2 generated) 1 centos7-desktop-tiny Template for CentOS 7 VM or newer. A PVC with the CentOS disk image must be a... 4 (2 generated) 1 centos7-server-large Template for CentOS 7 VM or newer. A PVC with the CentOS disk image must be a... 4 (2 generated) 1 centos7-server-medium Template for CentOS 7 VM or newer. A PVC with the CentOS disk image must be a... 4 (2 generated) 1 centos7-server-small Template for CentOS 7 VM or newer. A PVC with the CentOS disk image must be a... 4 (2 generated) 1 centos7-server-tiny Template for CentOS 7 VM or newer. A PVC with the CentOS disk image must be a... 4 (2 generated) 1 dancer-mysql-example An example Dancer application with a MySQL database. For more information abo... 18 (5 blank) 8 dancer-mysql-persistent An example Dancer application with a MySQL database. For more information abo... 19 (5 blank) 9 datagrid-service Red Hat Data Grid is an in-memory, distributed key/value store. 7 (1 blank) 4 datavirt64-basic-s2i Application template for JBoss Data Virtualization 6.4 services built using S2I. 20 (6 blank) 6 datavirt64-extensions-support-s2i An example JBoss Data Virtualization application. For more information about... 35 (9 blank) 10 datavirt64-ldap-s2i Application template for JBoss Data Virtualization 6.4 services that configur... 21 (6 blank) 6 datavirt64-secure-s2i An example JBoss Data Virtualization application. For more information about... 51 (22 blank) 8 decisionserver64-amq-s2i An example BRMS decision server A-MQ application. For more information about... 30 (5 blank) 10 decisionserver64-basic-s2i Application template for Red Hat JBoss BRMS 6.4 decision server applications... 17 (5 blank) 5 django-psql-example An example Django application with a PostgreSQL database. For more informatio... 19 (5 blank) 8 django-psql-persistent An example Django application with a PostgreSQL database. For more informatio... 20 (5 blank) 9 eap-xp3-basic-s2i Example of an application based on JBoss EAP XP. For more information about u... 20 (5 blank) 8 eap74-basic-s2i An example JBoss Enterprise Application Platform application. For more inform... 20 (5 blank) 8 eap74-https-s2i An example JBoss Enterprise Application Platform application configured with... 30 (11 blank) 10 eap74-sso-s2i An example JBoss Enterprise Application Platform application Single Sign-On a... 50 (21 blank) 10 fedora-desktop-large Template for Fedora 34 VM or newer. A PVC with the Fedora disk image must be... 4 (2 generated) 1 fedora-desktop-medium Template for Fedora 34 VM or newer. A PVC with the Fedora disk image must be... 4 (2 generated) 1 fedora-desktop-small Template for Fedora 34 VM or newer. A PVC with the Fedora disk image must be... 4 (2 generated) 1 fedora-desktop-tiny Template for Fedora 34 VM or newer. A PVC with the Fedora disk image must be... 4 (2 generated) 1 fedora-highperformance-large Template for Fedora 34 VM or newer. A PVC with the Fedora disk image must be... 4 (2 generated) 1 fedora-highperformance-medium Template for Fedora 34 VM or newer. A PVC with the Fedora disk image must be... 4 (2 generated) 1 fedora-highperformance-small Template for Fedora 34 VM or newer. A PVC with the Fedora disk image must be... 4 (2 generated) 1 fedora-highperformance-tiny Template for Fedora 34 VM or newer. A PVC with the Fedora disk image must be... 4 (2 generated) 1 fedora-server-large Template for Fedora 34 VM or newer. A PVC with the Fedora disk image must be... 4 (2 generated) 1 fedora-server-medium Template for Fedora 34 VM or newer. A PVC with the Fedora disk image must be... 4 (2 generated) 1 fedora-server-small Template for Fedora 34 VM or newer. A PVC with the Fedora disk image must be... 4 (2 generated) 1 fedora-server-tiny Template for Fedora 34 VM or newer. A PVC with the Fedora disk image must be... 4 (2 generated) 1 fuse710-console The Red Hat Fuse Console eases the discovery and management of Fuse applicati... 8 (1 blank) 5 httpd-example An example Apache HTTP Server (httpd) application that serves static content.... 9 (3 blank) 5 jenkins-ephemeral Jenkins service, without persistent storage.... 11 (all set) 7 jenkins-ephemeral-monitored Jenkins service, without persistent storage. ... 12 (all set) 8 jenkins-persistent Jenkins service, with persistent storage.... 13 (all set) 8 jenkins-persistent-monitored Jenkins service, with persistent storage. ... 14 (all set) 9 jws31-tomcat7-basic-s2i Application template for JWS applications built using S2I. 12 (3 blank) 5 jws31-tomcat7-https-s2i An example JBoss Web Server application configured for use with https. For mo... 17 (5 blank) 7 jws31-tomcat8-basic-s2i An example JBoss Web Server application. For more information about using thi... 12 (3 blank) 5 jws31-tomcat8-https-s2i An example JBoss Web Server application. For more information about using thi... 17 (5 blank) 7 jws56-openjdk11-tomcat9-ubi8-basic-s2i An example JBoss Web Server application. For more information about using thi... 10 (3 blank) 5 jws56-openjdk11-tomcat9-ubi8-https-s2i An example JBoss Web Server application. For more information about using thi... 15 (5 blank) 7 jws56-openjdk8-tomcat9-ubi8-basic-s2i An example JBoss Web Server application. For more information about using thi... 10 (3 blank) 5 jws56-openjdk8-tomcat9-ubi8-https-s2i An example JBoss Web Server application. For more information about using thi... 15 (5 blank) 7 mariadb-ephemeral MariaDB database service, without persistent storage. For more information ab... 8 (3 generated) 3 mariadb-persistent MariaDB database service, with persistent storage. For more information about... 9 (3 generated) 4 mysql-ephemeral MySQL database service, without persistent storage. For more information abou... 8 (3 generated) 3 mysql-persistent MySQL database service, with persistent storage. For more information about u... 9 (3 generated) 4 nginx-example An example Nginx HTTP server and a reverse proxy (nginx) application that ser... 10 (3 blank) 5 nodejs-postgresql-example An example Node.js application with a PostgreSQL database. For more informati... 18 (4 blank) 8 nodejs-postgresql-persistent An example Node.js application with a PostgreSQL database. For more informati... 19 (4 blank) 9 openjdk-web-basic-s2i An example Java application using OpenJDK. For more information about using t... 9 (1 blank) 5 postgresql-ephemeral PostgreSQL database service, without persistent storage. For more information... 7 (2 generated) 3 postgresql-persistent PostgreSQL database service, with persistent storage. For more information ab... 8 (2 generated) 4 processserver64-amq-mysql-persistent-s2i An example BPM Suite application with A-MQ and a MySQL database. For more inf... 49 (13 blank) 14 processserver64-amq-mysql-s2i An example BPM Suite application with A-MQ and a MySQL database. For more inf... 47 (13 blank) 12 processserver64-amq-postgresql-persistent-s2i An example BPM Suite application with A-MQ and a PostgreSQL database. For mor... 46 (10 blank) 14 processserver64-amq-postgresql-s2i An example BPM Suite application with A-MQ and a PostgreSQL database. For mor... 44 (10 blank) 12 processserver64-basic-s2i An example BPM Suite application. For more information about using this templ... 17 (5 blank) 5 processserver64-externaldb-s2i An example BPM Suite application with a external database. For more informati... 47 (22 blank) 7 processserver64-mysql-persistent-s2i An example BPM Suite application with a MySQL database. For more information... 40 (14 blank) 10 processserver64-mysql-s2i An example BPM Suite application with a MySQL database. For more information... 39 (14 blank) 9 processserver64-postgresql-persistent-s2i An example BPM Suite application with a PostgreSQL database. For more informa... 37 (11 blank) 10 rails-pgsql-persistent An example Rails application with a PostgreSQL database. For more information... 21 (4 blank) 9 rails-postgresql-example An example Rails application with a PostgreSQL database. For more information... 20 (4 blank) 8 redis-ephemeral Redis in-memory data structure store, without persistent storage. For more in... 5 (1 generated) 3 redis-persistent Redis in-memory data structure store, with persistent storage. For more infor... 6 (1 generated) 4 rhdm711-authoring Application template for a non-HA persistent authoring environment, for Red H... 76 (46 blank) 11 rhdm711-authoring-ha Application template for a HA persistent authoring environment, for Red Hat D... 92 (47 blank) 17 rhdm711-kieserver Application template for a managed KIE Server, for Red Hat Decision Manager 7... 61 (42 blank) 6 rhdm711-prod-immutable-kieserver Application template for an immutable KIE Server in a production environment,... 66 (45 blank) 8 rhdm711-prod-immutable-kieserver-amq Application template for an immutable KIE Server in a production environment... 80 (54 blank) 20 rhdm711-trial-ephemeral Application template for an ephemeral authoring and testing environment, for... 63 (40 blank) 8 rhel6-desktop-large Template for Red Hat Enterprise Linux 6 VM or newer. A PVC with the RHEL disk... 4 (2 generated) 1 rhel6-desktop-medium Template for Red Hat Enterprise Linux 6 VM or newer. A PVC with the RHEL disk... 4 (2 generated) 1 rhel6-desktop-small Template for Red Hat Enterprise Linux 6 VM or newer. A PVC with the RHEL disk... 4 (2 generated) 1 rhel6-desktop-tiny Template for Red Hat Enterprise Linux 6 VM or newer. A PVC with the RHEL disk... 4 (2 generated) 1 rhel6-server-large Template for Red Hat Enterprise Linux 6 VM or newer. A PVC with the RHEL disk... 4 (2 generated) 1 rhel6-server-medium Template for Red Hat Enterprise Linux 6 VM or newer. A PVC with the RHEL disk... 4 (2 generated) 1 rhel6-server-small Template for Red Hat Enterprise Linux 6 VM or newer. A PVC with the RHEL disk... 4 (2 generated) 1 rhel6-server-tiny Template for Red Hat Enterprise Linux 6 VM or newer. A PVC with the RHEL disk... 4 (2 generated) 1 rhel7-desktop-large Template for Red Hat Enterprise Linux 7 VM or newer. A PVC with the RHEL disk... 4 (2 generated) 1 rhel7-desktop-medium Template for Red Hat Enterprise Linux 7 VM or newer. A PVC with the RHEL disk... 4 (2 generated) 1 rhel7-desktop-small Template for Red Hat Enterprise Linux 7 VM or newer. A PVC with the RHEL disk... 4 (2 generated) 1 rhel7-desktop-tiny Template for Red Hat Enterprise Linux 7 VM or newer. A PVC with the RHEL disk... 4 (2 generated) 1 rhel7-highperformance-large Template for Red Hat Enterprise Linux 7 VM or newer. A PVC with the RHEL disk... 4 (2 generated) 1 rhel7-highperformance-medium Template for Red Hat Enterprise Linux 7 VM or newer. A PVC with the RHEL disk... 4 (2 generated) 1 rhel7-highperformance-small Template for Red Hat Enterprise Linux 7 VM or newer. A PVC with the RHEL disk... 4 (2 generated) 1 rhel7-highperformance-tiny Template for Red Hat Enterprise Linux 7 VM or newer. A PVC with the RHEL disk... 4 (2 generated) 1 rhel7-server-large Template for Red Hat Enterprise Linux 7 VM or newer. A PVC with the RHEL disk... 4 (2 generated) 1 rhel7-server-medium Template for Red Hat Enterprise Linux 7 VM or newer. A PVC with the RHEL disk... 4 (2 generated) 1 rhel7-server-small Template for Red Hat Enterprise Linux 7 VM or newer. A PVC with the RHEL disk... 4 (2 generated) 1 rhel7-server-tiny Template for Red Hat Enterprise Linux 7 VM or newer. A PVC with the RHEL disk... 4 (2 generated) 1 rhel8-desktop-large Template for Red Hat Enterprise Linux 8 VM or newer. A PVC with the RHEL disk... 4 (2 generated) 1 rhel8-desktop-medium Template for Red Hat Enterprise Linux 8 VM or newer. A PVC with the RHEL disk... 4 (2 generated) 1 rhel8-desktop-small Template for Red Hat Enterprise Linux 8 VM or newer. A PVC with the RHEL disk... 4 (2 generated) 1 rhel8-desktop-tiny Template for Red Hat Enterprise Linux 8 VM or newer. A PVC with the RHEL disk... 4 (2 generated) 1 rhel8-highperformance-large Template for Red Hat Enterprise Linux 8 VM or newer. A PVC with the RHEL disk... 4 (2 generated) 1 rhel8-highperformance-medium Template for Red Hat Enterprise Linux 8 VM or newer. A PVC with the RHEL disk... 4 (2 generated) 1 rhel8-highperformance-small Template for Red Hat Enterprise Linux 8 VM or newer. A PVC with the RHEL disk... 4 (2 generated) 1 rhel8-highperformance-tiny Template for Red Hat Enterprise Linux 8 VM or newer. A PVC with the RHEL disk... 4 (2 generated) 1 rhel8-server-large Template for Red Hat Enterprise Linux 8 VM or newer. A PVC with the RHEL disk... 4 (2 generated) 1 rhel8-server-medium Template for Red Hat Enterprise Linux 8 VM or newer. A PVC with the RHEL disk... 4 (2 generated) 1 rhel8-server-small Template for Red Hat Enterprise Linux 8 VM or newer. A PVC with the RHEL disk... 4 (2 generated) 1 rhel8-server-tiny Template for Red Hat Enterprise Linux 8 VM or newer. A PVC with the RHEL disk... 4 (2 generated) 1 rhel9-desktop-large Template for Red Hat Enterprise Linux 9 VM or newer. A PVC with the RHEL disk... 4 (2 generated) 1 rhel9-desktop-medium Template for Red Hat Enterprise Linux 9 VM or newer. A PVC with the RHEL disk... 4 (2 generated) 1 rhel9-desktop-small Template for Red Hat Enterprise Linux 9 VM or newer. A PVC with the RHEL disk... 4 (2 generated) 1 rhel9-desktop-tiny Template for Red Hat Enterprise Linux 9 VM or newer. A PVC with the RHEL disk... 4 (2 generated) 1 rhel9-highperformance-large Template for Red Hat Enterprise Linux 9 VM or newer. A PVC with the RHEL disk... 4 (2 generated) 1 rhel9-highperformance-medium Template for Red Hat Enterprise Linux 9 VM or newer. A PVC with the RHEL disk... 4 (2 generated) 1 rhel9-highperformance-small Template for Red Hat Enterprise Linux 9 VM or newer. A PVC with the RHEL disk... 4 (2 generated) 1 rhel9-highperformance-tiny Template for Red Hat Enterprise Linux 9 VM or newer. A PVC with the RHEL disk... 4 (2 generated) 1 rhel9-server-large Template for Red Hat Enterprise Linux 9 VM or newer. A PVC with the RHEL disk... 4 (2 generated) 1 rhel9-server-medium Template for Red Hat Enterprise Linux 9 VM or newer. A PVC with the RHEL disk... 4 (2 generated) 1 rhel9-server-small Template for Red Hat Enterprise Linux 9 VM or newer. A PVC with the RHEL disk... 4 (2 generated) 1 rhel9-server-tiny Template for Red Hat Enterprise Linux 9 VM or newer. A PVC with the RHEL disk... 4 (2 generated) 1 rhpam711-authoring Application template for a non-HA persistent authoring environment, for Red H... 80 (46 blank) 12 rhpam711-authoring-ha Application template for a HA persistent authoring environment, for Red Hat P... 101 (47 blank) 20 rhpam711-kieserver-externaldb Application template for a managed KIE Server with an external database, for... 83 (59 blank) 8 rhpam711-kieserver-mysql Application template for a managed KIE Server with a MySQL database, for Red... 70 (42 blank) 9 rhpam711-kieserver-postgresql Application template for a managed KIE Server with a PostgreSQL database, for... 71 (42 blank) 9 rhpam711-managed Application template for a managed HA production runtime environment, for Red... 87 (46 blank) 14 rhpam711-prod Application template for a managed HA production runtime environment, for Red... 102 (55 blank) 28 rhpam711-prod-immutable-kieserver Application template for an immutable KIE Server in a production environment,... 76 (45 blank) 11 rhpam711-prod-immutable-kieserver-amq Application template for an immutable KIE Server in a production environment... 97 (58 blank) 23 rhpam711-prod-immutable-monitor Application template for a router and monitoring console in a production envi... 66 (44 blank) 14 rhpam711-trial-ephemeral Application template for an ephemeral authoring and testing environment, for... 63 (40 blank) 8 s2i-fuse710-spring-boot-2-camel Spring Boot 2 and Camel QuickStart. This example demonstrates how you can use... 18 (3 blank) 3 s2i-fuse710-spring-boot-2-camel-rest-3scale Spring Boot 2, Camel REST DSL and 3Scale QuickStart. This example demonstrate... 19 (3 blank) 5 s2i-fuse710-spring-boot-2-camel-xml Spring Boot 2 and Camel Xml QuickStart. This example demonstrates how you can... 18 (3 blank) 3 sso72-https An example RH-SSO 7 application. For more information about using this templa... 26 (15 blank) 6 sso72-mysql An example RH-SSO 7 application with a MySQL database. For more information a... 36 (20 blank) 8 sso72-mysql-persistent An example RH-SSO 7 application with a MySQL database. For more information a... 37 (20 blank) 9 sso72-postgresql An example RH-SSO 7 application with a PostgreSQL database. For more informat... 33 (17 blank) 8 sso72-postgresql-persistent An example RH-SSO 7 application with a PostgreSQL database. For more informat... 34 (17 blank) 9 sso73-https An example application based on RH-SSO 7.3 image. For more information about... 27 (16 blank) 6 sso73-mysql An example application based on RH-SSO 7.3 image. For more information about... 37 (21 blank) 8 sso73-mysql-persistent An example application based on RH-SSO 7.3 image. For more information about... 38 (21 blank) 9 sso73-ocp4-x509-https An example application based on RH-SSO 7.3 image. For more information about... 13 (7 blank) 5 sso73-ocp4-x509-mysql-persistent An example application based on RH-SSO 7.3 image. For more information about... 24 (12 blank) 8 sso73-ocp4-x509-postgresql-persistent An example application based on RH-SSO 7.3 image. For more information about... 21 (9 blank) 8 sso73-postgresql An example application based on RH-SSO 7.3 image. For more information about... 34 (18 blank) 8 sso73-postgresql-persistent An example application based on RH-SSO 7.3 image. For more information about... 35 (18 blank) 9 sso74-https An example application based on RH-SSO 7.4 on OpenJDK image. For more informa... 27 (16 blank) 6 sso74-ocp4-x509-https An example application based on RH-SSO 7.4 on OpenJDK image. For more informa... 13 (7 blank) 5 sso74-ocp4-x509-postgresql-persistent An example application based on RH-SSO 7.4 on OpenJDK image. For more informa... 21 (9 blank) 8 sso74-postgresql An example application based on RH-SSO 7.4 on OpenJDK image. For more informa... 34 (18 blank) 8 sso74-postgresql-persistent An example application based on RH-SSO 7.4 on OpenJDK image. For more informa... 35 (18 blank) 9 sso75-https An example application based on RH-SSO 7.5 on OpenJDK image. For more informa... 27 (16 blank) 6 sso75-ocp4-x509-https An example application based on RH-SSO 7.5 on OpenJDK image. For more informa... 13 (7 blank) 5 sso75-ocp4-x509-postgresql-persistent An example application based on RH-SSO 7.5 on OpenJDK image. For more informa... 21 (9 blank) 8 sso75-postgresql An example application based on RH-SSO 7.5 on OpenJDK image. For more informa... 34 (18 blank) 8 sso75-postgresql-persistent An example application based on RH-SSO 7.5 on OpenJDK image. For more informa... 35 (18 blank) 9 windows10-desktop-large Template for Microsoft Windows 10 VM. A PVC with the Windows disk image must... 3 (1 generated) 1 windows10-desktop-medium Template for Microsoft Windows 10 VM. A PVC with the Windows disk image must... 3 (1 generated) 1 windows10-highperformance-large Template for Microsoft Windows 10 VM. A PVC with the Windows disk image must... 3 (1 generated) 1 windows10-highperformance-medium Template for Microsoft Windows 10 VM. A PVC with the Windows disk image must... 3 (1 generated) 1 windows2k12r2-highperformance-large Template for Microsoft Windows Server 2012 R2 VM. A PVC with the Windows disk... 3 (1 generated) 1 windows2k12r2-highperformance-medium Template for Microsoft Windows Server 2012 R2 VM. A PVC with the Windows disk... 3 (1 generated) 1 windows2k12r2-server-large Template for Microsoft Windows Server 2012 R2 VM. A PVC with the Windows disk... 3 (1 generated) 1 windows2k12r2-server-medium Template for Microsoft Windows Server 2012 R2 VM. A PVC with the Windows disk... 3 (1 generated) 1 windows2k16-highperformance-large Template for Microsoft Windows Server 2016 VM. A PVC with the Windows disk im... 3 (1 generated) 1 windows2k16-highperformance-medium Template for Microsoft Windows Server 2016 VM. A PVC with the Windows disk im... 3 (1 generated) 1 windows2k16-server-large Template for Microsoft Windows Server 2016 VM. A PVC with the Windows disk im... 3 (1 generated) 1 windows2k16-server-medium Template for Microsoft Windows Server 2016 VM. A PVC with the Windows disk im... 3 (1 generated) 1 windows2k19-highperformance-large Template for Microsoft Windows Server 2019 VM. A PVC with the Windows disk im... 3 (1 generated) 1 windows2k19-highperformance-medium Template for Microsoft Windows Server 2019 VM. A PVC with the Windows disk im... 3 (1 generated) 1 windows2k19-server-large Template for Microsoft Windows Server 2019 VM. A PVC with the Windows disk im... 3 (1 generated) 1 windows2k19-server-medium Template for Microsoft Windows Server 2019 VM. A PVC with the Windows disk im... 3 (1 generated) 1 Additionally, you may copy and customize these templates if you wish. The template file is an example of a customized template that was used to help develop this pattern.
+Creating a VM from the Console via Template These templates can be run through the OpenShift Console from the Virtualization tab. Note the &ldquo;Create VM&rdquo; buttons on the right side of this picture:
+Clicking on the &ldquo;Create VM&rdquo; button will bring up a wizard that looks like this:
+Accepting the defaults from this wizard will give a success screen:
+Until it is deleted, you can monitor the machine&rsquo;s lifecycle from the VirtualMachines tab:
+This is a great way to gain familiarity with how the system works, but we might possibly want an interface we can use more programmatically.
+Creating a VM from the command line via oc process This is a useful way to understand what kinds of objects OpenShift Virtualization creates and manages:
+$ oc process -n openshift rhel8-desktop-medium | oc apply -f - virtualmachine.kubevirt.io/rhel8-q63yuvxpjdvy18l7 created You could also use the &ldquo;Create VM Wizard&rdquo; in the OpenShift console.
+Another option - capturing template output and converting it into a Helm Chart See details here.
+Components of the virtual-machines template Setup - the mechanism for creating identifiers declaratively The first part of the template file sets up some variables that we will use later as the template is expanded. We use a sequential numbering scheme for VM name creation because that is an easy way to make each item in the set declarative - it ensures that if you ask for 5 VMs of a particular type, they will have predictable names, and if one is deleted, it will be replaced by a VM with the same name.
+We use explicit &ldquo;range&rdquo; variables for the Go templating. This is because the implicit range variable is easily &ldquo;trampled&rdquo;, and we have at least two different dimensions to iterate on - vm &ldquo;role&rdquo; and &ldquo;index&rdquo; within that role.
+The External Secret - SSH pubkey The first item we define as part of this structure is an external secret to hold an SSH pubkey. This pubkey will be mounted in the VM under an unprivileged user&rsquo;s home directory - and generally that unprivileged user is expected to be able to sudo root without password. By default, RHEL images are configured to only allow SSH access via pubkey. In this pattern, the private key and public key for the SSH connections are loaded into both Vault (which we inherited from previous patterns) and Ansible Automation Platform.
+Since the keys are defined per VM &ldquo;group&rdquo;, it is possible and expected that you could have different keypairs for different groups of VMs. Nothing would prevent you from using the same keypair for all machines if you have different groups, though.
+While the pubkey is not truly a &ldquo;secret&rdquo;, the availability of the External Secrets Operator made for a nice opportunity to allow for variance in configuration without necessarily requiring local customization of the pattern. The OpenShift Virtualization model has no way of knowing that multiple servers may have the same SSH credentials, and in fact cannot depend on this. So it creates a pubkey object by default for each VM, and we imitate this behavior in the pattern.
+The VirtualMachine definition The VirtualMachine definition is the biggest part of the template. All of it is derived from customization of the default templates that OpenShift Virtualization installs in the openshift namespace - especially most of the labels and annotations, with the following exceptions:
+labels app This is set to $identifier to match a general pattern with other applications.
+edge-gitops-role This is set explicitly and used elsewhere in this pattern to help identify resources by role. The intention is to be able to use the edge-gitops-role as a selector for targeting various kind of queries, including (especially) Ansible inventories. Though please note - because of the way Kubernetes (and OpenShift) work, when you connect to a VM with Ansible you are connecting to the Service object directly, not to the VM. (Another way to look at it is that the Service object is providing network abstraction over the VM object.)
+Other resources in the rest of the VirtualMachine definition are copied from the default template, with appropriate Helm variables included.
+Initial user access Note that the initial user (default: cloud-user) and initial password are customizable via values overrides. The kiosk type shows an example of how to either use a user/password specific to the type or a default for the chart using the coalesce function.
+The Service definition The Service definition is potentially complex. The purpose of this Service object is to expose all of the needed TCP and UDP network ports within the cluster. (Providing access to them from outside the cluster would require Route or Ingress objects, and would have some significant security implications; access to these entities from outside the cluster is not the focus of this pattern, so we do not provide it at this time.)
+A given VM may expose one port (for Ansible access, you need at least TCP/22), or it may expose many ports. You are free to define a service per port if you like, but it seems more convenient to define them all as a single service.
+One aspect of the templating you may find interesting is the use of the toPrettyJson filter in Go. Since YAML is a proper superset of JSON, this is a neat trick that allows to include a nested data structure without having to worry about how to indent it. (As toPrettyJson uses the square bracket ([]) and curly bracket ({}) notation for arrays and hashes, YAML can interpret it without worrying about its indentation.
+Accessing the VMs There are three mechanisms for access to these VMs:
+Ansible - keypair authentication The ssh keypairs from your values-secret.yaml are loaded into both Vault and AAP for use later. The pattern currently defines one such keypair, kiosk-ssh, but could support more, such as iot-ssh, gateway-ssh, etc. more details on how to expand on this pattern are described below.
+AAP only needs the private key and the username as a machine credential. The public key is not truly a secret, but it seemed interesting and useful to use the external secret operator to associate the public key with VM instances this way and prevent having to diverge from the upstream pattern to include local ssh pubkey specifications.
+Note that the default SSH setting for RHEL does not allow password-based logins via SSH, and it&rsquo;s at the very least inconvenient to copy the SSH private key into a VM inside the cluster, so the typical way the keypair will be used is through Ansible.
+Virtual Machine Console Access via OpenShift Console Navigate to Virtualization -&gt; VirtualMachines and make sure Project: All Projects or edge-gitops-vms is selected:
+Click on the &ldquo;three dots&rdquo; menu on the right, which will open a dialog like the following:
+Note: In OpenShift Virtualization 4.11, the &ldquo;Open Console&rdquo; option appears when you click on the virtual machine name in openshift console. The dialog looks like this:
+The virtual machine console view will either show a standard RHEL console login screen, or if the demo is working as designed, it will show the Ignition application running in kiosk mode. If the console shows a standard RHEL login, it can be accessed using the the initial user name (cloud-user by default) and password (which is what is specified in the Helm chart Values as either the password specific to that machine group, the default cloudInit, or a hardcoded default which can be seen in the template here. On a VM created through the wizard or via oc process from a template, the password will be set on the VirtualMachine object in the volumes section.
+Initial User login (cloud-user) In general, and before the VMs have been configured by the Ansible Jobs, you can log in to the VMs on the console using the user and password you specified in the Helm chart, or else you can look at the VirtualMachine object and see what the username and password setting are. The pattern, by design, replaces the typical console view with Firefox running in kiosk mode. But this mechanism can still be used if you change the console from &ldquo;VNC Console&rdquo; to &ldquo;Serial Console&rdquo;.
+The &ldquo;extra&rdquo; VM Template Also included in the edge-gitops-vms chart is a separate template that will allow the creation of VMs with similar (though not identical characteristics) to the ones defined in the chart.
+The rhel8-kiosk-with-svc template is preserved as an intermediate step to creating your own VM types, to see how the pipeline from default VM template -&gt; customized template -&gt; Helm-variable chart can work.
+Next Steps Help &amp; Feedback Report Bugs `,url:"https://validatedpatterns.io/patterns/ansible-edge-gitops/openshift-virtualization/",breadcrumb:"/patterns/ansible-edge-gitops/openshift-virtualization/"},"https://validatedpatterns.io/learn/test-artifacts/":{title:"Testing Artifacts",tags:[],content:`Testing artifacts 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 Red Hat OpenShift Container Platform version.
+File naming convention {pattern}-{platform}-{openshift version}-stable-badge.json
+Example: medicaldiag-nutanix-4.13-stable-badge.json
+Note: OpenShift version should be major.minor only
+File template { &#34;schemaVersion&#34;:1, &#34;label&#34;:&#34;{text}&#34;, /* For now we assume \`message\` is the same as patternBranch */ &#34;message&#34;:&#34;{text}&#34;, /* passed =&gt; green, test failed =&gt; red, test setup failed =&gt; yellow */ &#34;color&#34;:&#34;{test result color}&#34;, /* eg. x.y.z */ &#34;openshiftVersion&#34;:&#34;{full openshift version}&#34;, /* eg. AWS, GCP, Nutanix, ... */ &#34;infraProvider&#34;:&#34;{platform}&#34;, /* Official repo of the pattern, eg. https://github.com/validatedpatterns/multicloud-gitops */ &#34;patternRepo&#34;: &#34;{text}&#34;, /* eg. main, stable-N.M */ &#34;patternBranch&#34;: &#34;{text}&#34;, &#34;date&#34;:&#34;{YYYY-MM-DD}&#34;, /* Who ran the test eg. Red Hat */ &#34;testSource&#34;: &#34;{company name}&#34;, /* eg. Job number */ &#34;testID&#34;: &#34;{unique id}&#34;, /* if publically available */ &#34;jenkinsURL&#34;:&#34;{path to job}&#34;, &#34;debugInfo&#34;:&#34;{location of must-gather tarball}&#34;, } Example testing artifact file { &#34;schemaVersion&#34;:1, &#34;label&#34;:&#34;MCG on Nutanix&#34;, &#34;message&#34;:&#34;main&#34;, &#34;color&#34;:&#34;green&#34;, &#34;openshiftVersion&#34;:&#34;4.13.14&#34;, &#34;infraProvider&#34;:&#34;Nutanix&#34;, &#34;patternRepo&#34;: &#34;https://github.com/validatedpatterns/multicloud-gitops&#34;, &#34;patternBranch&#34;: &#34;main&#34;, &#34;date&#34;:&#34;2023-10-23&#34;, &#34;testSource&#34;: &#34;Red Hat&#34; &#34;testID&#34;: &#34;13602&#34;, &#34;jenkinsURL&#34;:&#34;https://jenkins/job/ValidatedPatterns/job/MedicalDiagnosis/job/medicaldiag-gcp-ocp4.13/37/&#34;, &#34;debugInfo&#34;:&#34;https://storage.cloud.google.com/.../medicaldiag-gcp-ocp4.13.15-13602.tgz&#34;, } `,url:"https://validatedpatterns.io/learn/test-artifacts/",breadcrumb:"/learn/test-artifacts/"},"https://validatedpatterns.io/learn/using-validated-pattern-operator/":{title:"Using the Validated Patterns Operator",tags:[],content:`About the Validated Patterns Operator You can use the Validated Patterns Operator to install and manage Validated Patterns. Use the Red Hat Hybrid Cloud Console to install the Validated Patterns Operator. After installing the Operator, you can create an instance where you can specify the details for your pattern. The Validated Patterns Operator then installs and manages the required assets and artifacts that the pattern requires.
+Installing the Validated Patterns Operator Prerequisites Access to an OpenShift Container Platform cluster using an account with cluster-admin permissions.
+Procedure Navigate in the Red Hat Hybrid Cloud Console to the Operators → OperatorHub page.
+Scroll or type a keyword into the Filter by keyword box to find the Operator you want. For example, type validated patterns to find the Validated Patterns Operator.
+Select the Operator to display additional information.
+Choosing a Community Operator warns that Red Hat does not certify Community Operators; you must acknowledge the warning before continuing.
+Read the information about the Operator and click Install.
+On the Install Operator page:
+Select an Update channel (if more than one is available).
+Select a Version (if more than one is available).
+Select an Installation mode:
+All namespaces on the cluster (default) installs the Operator in the default openshift-operators namespace to watch and be made available to all namespaces in the cluster. This option is not always available.
+A specific namespace on the cluster allows you to choose a specific, single namespace in which to install the Operator. The Operator will only watch and be made available for use in this single namespace.
+Select Automatic or Manual approval strategy.
+Click Install to make the Operator available to the selected namespaces on this OpenShift Container Platform cluster.
+Verification To confirm that the installation is successful:
+Navigate to the Operators → Installed Operators page.
+Check that the Operator is installed in the selected namespace and its status is Succeeded.
+Creating a pattern instance Prerequisites The Validated Patterns Operator is successfully installed in the relevant namespace.
+Procedure Navigate to the Operators → Installed Operators page.
+Click the installed Validated Patterns Operator.
+Under the Details tab, in the Provided APIs section, in the Pattern box, click Create Instance that displays the Create Pattern page.
+On the the Create Pattern page, select Form view and enter information in the following fields:
+Name - A name for the pattern deployment that is used in the projects that you created.
+Labels - Apply any other labels you might need for deploying this pattern.
+Cluster Group Name - Select a cluster group name to identify the type of cluster where this pattern is being deployed. For example, if you are deploying the Industrial Edge pattern, the cluster group name is datacenter. If you are deploying the Multicloud GitOps pattern, the cluster group name is hub.
+To know the cluster group name for the patterns that you want to deploy, check the relevant pattern-specific requirements.
+Expand the Git Config section to reveal the options and enter the required information.
+Change the Target Repo URL to your forked repository URL. For example, change https://github.com/validatedpatterns/&lt;pattern_name&gt; to https://github.com/&lt;your-git-username&gt;/&lt;pattern-name&gt;
+Optional: You might need to change the Target Revision field. The default value is HEAD. However, you can also provide a value for a branch, tag, or commit that you want to deploy. For example, v2.1, main, or a branch that you created, my-branch.
+Ensure that you have made any required changes to your values-*.yaml files locally and pushed them to your forked repository on the correct branch or target that you chose in the previous step.
+Click Create.
+Verification The Red Hat OpenShift GitOps Operator displays in list of Installed Operators. The Red Hat OpenShift GitOps Operator installs the remaining assets and artifacts for this pattern. To view the installation of these assets and artifacts, such as Red Hat Advanced Cluster Management (RHACM), ensure that you switch to Project:All Projects.
+For more information about post-installation instructions for a pattern, see its Getting started page.
+`,url:"https://validatedpatterns.io/learn/using-validated-pattern-operator/",breadcrumb:"/learn/using-validated-pattern-operator/"},"https://validatedpatterns.io/learn/clustergroup-in-values-files/":{title:"ClusterGroup in Values Files",tags:[],content:`ClusterGroup configuration in values files ClusterGroup serves as a centralized control mechanism, enabling the grouping of clusters based on specific criteria such as geographic location, project, or application type. This feature enhances cluster management efficiency by facilitating the coordination of multiple clusters within the system.
+In the validated patterns framework, the ClusterGroup holds a pivotal role, defined as an individual entity or a collection of clusters, each representing a unique configuration class. This foundational concept uses Helm charts and Kubernetes features to determine its attributes.
+Typically, a ClusterGroup represents a singular cluster, serving as the foundation for each validated pattern. However, it can also encompass managed ClusterGroups tailored for replication or scaling efforts. Each pattern requires at least one ClusterGroup, with the primary one often named arbitrarily. This designation is defined in values-global.yaml under the key main.clusterGroupName, with &#34;Hub&#34; commonly used as a default. Alternatively, other names are acceptable. For example, if main.clusterGroupName is &#34;hub,&#34; the framework searches for values-hub.yaml in the pattern’s root directory. It’s important to note that the main ClusterGroup is typically a singleton and may incorporate Red Hat Advanced Cluster Management (RHACM) if part of the pattern.
+Additionally, the main ClusterGroup can define managedClusterGroups in its values file, specifying characteristics and policies for spoke clusters, which can be singletons or groups.
+Basic parameters configuration in a ClusterGroup You can set foundational parameters within a ClusterGroup, including cluster location, version, and networking settings. By configuring these basic parameters, you can establish the initial framework for managing and provisioning clusters within the group. These parameters include:
+Name: Assigns a unique identifier to the ClusterGroup, acting as a reference point for identification within the broader infrastructure.
+TargetCluster: Specifies the primary cluster(s) associated with the ClusterGroup, guiding management and control within its scope. The default is &#34;in-cluster,&#34; which is a reasonable default. However, it can be changed when using the &#34;push&#34; model of OpenShift GitOps.
+IsHubCluster: Indicates whether the designated cluster serves as a hub cluster, centralizing coordination and management within the ClusterGroup. Each Validated Pattern may have at most one cluster designated as a Hub cluster. This designation affects the use of Red Hat Advanced Cluster Management within the Validated Patterns framework.
+SharedValueFiles: Enables specification of shared values files containing configuration settings shared across multiple clusters within the ClusterGroup, promoting consistency and simplifying configuration management. Each sharedValueFiles is applied as a value file to every application designated for installation in the clusterGroup.
+OperatorgroupExcludes: Allows exclusion of specific operator groups from being applied to clusters within the ClusterGroup, providing flexibility in customizing operator deployment and management.
+Projects: Defines OpenShift GitOps projects to facilitate grouping applications. Each application must reference a project.
+By configuring these basic parameters in a ClusterGroup, you can effectively establish the foundational elements necessary for organizing, managing, and coordinating clustered resources.
+Namespace configuration in a ClusterGroup Namespace configuration within a ClusterGroup enables effective workload management and organization by logically partitioning and isolating resources and applications. This feature enhances security, facilitates resource allocation, and simplifies administrative tasks by creating distinct namespaces within the ClusterGroup.
+The namespace parameter in a Kubernetes Helm chart specifies namespaces within the ClusterGroup, enabling access control enforcement, resource allocation, and workload segregation according to specific requirements or organizational policies.
+Sub-parameters Name: Specifies the name of the namespace to be created within the ClusterGroup.
+Labels: Allows you to assign labels or tags to the namespace for categorization and identification purposes.
+Annotations: Provides additional metadata or descriptive information about the namespace for documentation or management purposes.
+Examples: Namespaces without extra labels and annotations (from the multicloud gitops pattern):
+namespaces: - open-cluster-management - vault - golang-external-secrets - config-demo - hello-world Namespaces with Labels and Annotations:
+namespaces: open-cluster-management: {} vault: {} golang-external-secrets: {} config-demo: labels: app: &#39;config-demo&#39; tier: &#39;test&#39; annotations: &#39;test/annotation&#39;: true hello-world: {} In this example, we add “app” and “tier” labels to the config-demo app, and the annotation “test/annotation: true” to it. All other namespaces are created with defaults.
+Subscription configuration in a ClusterGroup Configuring subscriptions within a ClusterGroup streamlines access management and resource allocation for users and applications. It also facilitates the creation of a software bill of materials detailing the intended installations for the ClusterGroup.This capability empowers you to establish subscription plans, enforce governance policies, and ensure optimal resource utilization. Through the subscriptions parameter, you can define access levels, allocate resources, and promote efficient management and cost optimization within the ClusterGroup environment.
+Subscriptions are the preferred way of including OpenShift operators in the validated patterns. Known as OLM Packages (OLM for Operator Lifecycle Manager), these subscriptions function similarly to RPM packages for RHEL, with operators responsible for software operation and upgrades.
+Sub-parameters Name: The name of the package to install.
+Source: Specifies which catalog to use for packages. The default is “redhat-operators,” which should only be changed if you want to install pre-release operators.
+SourceNamespace: Specifies which namespace to use for the catalog. The default is “openshift-marketplace,” which should only be changed if you want to install a pre-release operator.
+Channel: Indicates the default “channel” for updates, usually corresponding to major versions of the operator. While operators define a default channel for each major version of OpenShift they support, specifying a particular channel is optional unless you wish to use a non-default one. There is no standard naming convention for channels. They can be named &#34;stable&#34;, &#34;development&#34;, or &#34;2.9&#34;, among others.
+InstallPlanApproval: Defaults to “automatic,” allowing the operator to periodically check and update itself. Alternatively, it can be set to “manual,” meaning operators will only upgrade when triggered by an administrator.
+Config: Primarily consists of an “env:” key that allows environment variables to be passed to the operator.
+UseCSV: Specifies whether to use specific “cluster service versions” for installation. Defaults to false; the channel primarily determines the installed version.
+StartingCSV: Determines the lowest “cluster service version” to consider installing. If installPlanApproval is “manual,” only this version will be considered for installation.
+Disabled: Optional boolean (defaults to false). Prevents the installation of a subscription specified higher in the value hierarchy. For example, if an Operator is incompatible with Azure, the default pattern may include the installation of the subscription. However, an Azure-specific configuration file could specify disabled: true, thereby skipping the installation of the operator on Azure.
+Examples: Subscriptions for multicloud-gitops (just ACM):
+subscriptions: acm: name: advanced-cluster-management namespace: open-cluster-management channel: release-2.10 Subscriptions for Industrial Edge (many more):
+subscriptions: acm: name: advanced-cluster-management namespace: open-cluster-management amqbroker-prod: name: amq-broker-rhel8 namespace: manuela-tst-all amqstreams-prod-dev: name: amq-streams namespaces: - manuela-data-lake - manuela-tst-all camelk-prod-dev: name: red-hat-camel-k namespaces: - manuela-data-lake - manuela-tst-all seldon-prod-dev: name: seldon-operator-certified namespaces: - openshift-operators source: certified-operators pipelines: name: openshift-pipelines-operator-rh source: redhat-operators odh: name: opendatahub-operator source: community-operators Subscriptions for Ansible Edge GitOps (demonstrating disable and override):
+subscriptions: acm: name: advanced-cluster-management namespace: open-clustsubscriptions: openshift-data-foundation: disabled: true portworx: name: portworx-certified namespace: portworx channel: stable source: certified-operators er-management channel: release-2.10 In this example, the values file is intended to override the default settings in the main values-hub.yaml. Consequently, the openshift-data-foundation application is overridden and disabled, while the portworx application is added.
+Managed cluster groups configuration in a ClusterGroup Configuring managed cluster groups within a ClusterGroup enhances the organizational structure and simplifies resource management. Through the managedClusterGroups parameter, you can define and organize clusters based on specific criteria, promoting efficient management and resource allocation within the ClusterGroup. This functionality streamlines management and coordination tasks across the infrastructure. Managed ClusterGroups mirror the configuration of a single cluster, facilitating the deployment of identical applications or implementing minor configuration adjustments across multiple clusters.
+This feature implies the existence of a values-{name}.yaml file in the pattern directory root, containing the clusterGroup definition for the managed clusterGroup. It can have its subscriptions, applications, namespaces, and projects, which may or may not reflect those of the hub clusterGroup.
+Sub-parameters Name: Provides a descriptive identifier for organizational purposes.
+HelmOverrides: Adds values to helm-based applications in the managed clustergroup to adjust cluster configuration based on policy. Each override is specified with a name: and value: parameter.
+ClusterSelector: Specifies attributes that the Hub cluster’s Red Hat Advanced Cluster Management instance uses to determine whether or not to assign the clusterGroup policy to a cluster joined to it.
+Examples: ManagedClusterGroups block within the Industrial Edge pattern:
+managedClusterGroups: factory: name: factory helmOverrides: # Values must be strings! - name: clusterGroup.isHubCluster value: &#34;false&#34; clusterSelector: matchLabels: clusterGroup: factory matchExpressions: - key: vendor operator: In values: - OpenShift In this example the helmOverrides section applies helm overrides to the applications in the declared clusterGroup. The clusterSelector has two matching criteria: it seeks a label &#34;clusterGroup&#34; with the value &#34;factory&#34;, and the vendor must be &#34;OpenShift&#34;. When these conditions are met, the policy is enacted, and the namespaces, projects, subscriptions, and applications outlined in values-factory.yaml are applied.
+Multiple clusters may match a single managedClusterGroup definition, providing flexibility in deployment.
+ManagedClusterGroups block within the retail pattern:
+managedClusterGroups: raleigh: name: store-raleigh helmOverrides: # Values must be strings! - name: clusterGroup.isHubCluster value: &#34;false&#34; clusterSelector: matchLabels: clusterGroup: store-raleigh matchExpressions: - key: vendor operator: In values: - OpenShift In this example, we look for an OpenShift cluster labeled with &#34;store-raleigh&#34; as its clusterGroup. Additionally, the option of implementing more clusterSelectors and overrides are also possible for specific customization needs.
+Applications configuration in a ClusterGroup Configuring applications within a ClusterGroup streamlines the process of defining, configuring, and coordinating software applications efficiently across clustered environments. The applications parameter allows you to specify the properties, dependencies, and resources required for each application deployment within the ClusterGroup, ensuring consistent and efficient deployment across multiple clusters.
+In this context, applications refer to those defined by the OpenShift GitOps Operator. These do not need to be applications in the traditional sense but are discrete units of deployment. The Validated Patterns framework supports any type of application that OpenShift GitOps can manage, but the most commonly used type is a Helm chart co-located in the repository that defines the pattern.
+Sub-parameters Name: Specifies the name of the application, providing a unique identifier for management purposes.
+Namespace: (Mandatory) : The namespace that the application will be deployed into.
+Project: The OpenShift GitOps project associated with the application, used for OpenShift GitOps grouping.
+Path: The path, relative to the pattern repository, that contains the application. For a Helm chart, this should be the top level of the Helm structure, including chart.yaml, a templates directory, and a values.yaml to define default values.
+Kustomize: A boolean indicating whether the application is a Kustomize artifact. If true, it will disable Helm chart processing options. Kustomize artifacts are fully supported by the framework.
+Overrides: (Optional): Defines value-by-value overrides for a Helm chart. Each override must include a name and a value. The name specifies the variable being overridden, and the value is what will be used to override it in the template. Overrides have the highest priority among Helm variables.
+Plugin: Uses a custom-defined GitOps Config Management Plugin. These plugins offer functionality beyond the standard Helm and Kustomize support provided by the OpenShift GitOps Operator. More information on defining config management plugins in the framework can be found in Argo CD config management plugins in Validated Patterns.
+IgnoreDifferences: A structure given to OpenShift GitOps to programmatically not consider differences as “out of sync.” Use this when the data structures are expected to be out of sync because of different (and expected) cluster metadata or security configurations.
+ExtraValueFiles: A list of additional value files passed to the Helm chart to render the templates. These files override the defaults in the chart’s values.yaml. For hub clusters, the framework automatically parses “automatic” variables.
+Examples: odf: name: odf namespace: openshift-storage project: hub path: charts/hub/openshift-data-foundations extraValueFiles: - &#39;/overrides/values-odf-{{ $.Values.global.clusterPlatform }}-{{ $.Values.global.clusterVersion }}.yaml&#39; When the framework renders this block, it uses the cluster settings for global.clusterPlatform and global.clusterVersion. For instance, if there’s a file /overrides/values-odf-AWS-4.11.yaml, and the cluster is running on AWS and OpenShift 4.11, those values will be used by the chart. The framework ensures that missing value files do not cause errors. If the pattern is running on a different platform or cluster version, this construction will not cause an error; the values will simply be ignored. Using variables for extraValueFiles is optional. You can also use constant text and paths. The Industrial Edge pattern does this and employs GitOps workflows to edit the values files in place:
+test: name: manuela-test namespace: manuela-tst-all project: datacenter path: charts/datacenter/manuela-tst extraValueFiles: - /overrides/values-test-imagedata.yaml Imperative values configuration in a ClusterGroup The imperative parameter in a ClusterGroup allows direct specification of essential configurations for managing clustered resources, bypassing default settings. This encompasses tasks requiring cluster-wide access, like distributing certificates or access tokens. Within this framework, a pod (a group of containers) is defined to execute specific functions on each cluster within the ClusterGroup, rerunning jobs periodically. You can specify any container image and associated commands for sequential execution. While not mandatory, Ansible facilitates writing imperative jobs, with all values passed as Ansible and Helm values.
+Sub-parameters Parameter Name: Specifies the name of the parameter or property to be configured imperatively within the ClusterGroup.
+Value: Defines the value for the specified parameter, ensuring it is explicitly configured within the ClusterGroup.
+Scope: Specifies the scope or context in which the imperative value applies, such as a specific application or resource group within the ClusterGroup.
+Examples: jobs: - name: deploy-kubevirt-worker playbook: ansible/deploy_kubevirt_worker.yml verbosity: -vvv - name: configure-aap-controller playbook: ansible/imperative_configure_controller.yml image: quay.io/hybridcloudpatterns/ansible-edge-gitops-ee:latest verbosity: -vvv timeout: &#34;900&#34; clusterRoleYaml: - apiGroups: - &#34;*&#34; resources: - machinesets verbs: - &#34;*&#34; - apiGroups: - &#34;*&#34; resources: - &#34;*&#34; verbs: - get - list - watch In this example, the imperative section defines two jobs, &#34;deploy-kubevirt-worker&#34; and &#34;configure-aap-controller&#34;.
+The &#34;deploy-kubevirt-worker&#34; job is responsible for ensuring that the cluster runs on AWS. It uses the OpenShift MachineSet API to add a baremetal node for running virtual machines.
+The &#34;configure-aap-controller&#34; job sets up the Ansible Automation Platform (AAP), a crucial component of the Ansible Edge GitOps platform. This job entitles AAP and sets up projects, jobs, and credentials. Unlike the default container image, this example uses a different image.
+Additionally, an optional clusterRoleYaml section is defined. By default, the imperative job runs under Role-based access control (RBAC), providing read-only access to all resources within its cluster. However, if a job requires write access to alter or generate settings, such permissions can be specified within the clusterRoleYaml section. In the AnsibleEdge scenario, the &#34;deploy-kubevirt-worker&#34; job needs permissions to manipulate and create machinesets, while the &#34;configure-aap-controller&#34; job requires read-only access to Kubernetes objects.
+`,url:"https://validatedpatterns.io/learn/clustergroup-in-values-files/",breadcrumb:"/learn/clustergroup-in-values-files/"},"https://validatedpatterns.io/patterns/ansible-edge-gitops-kasten/veeam-kasten/":{title:"Veeam Kasten",tags:[],content:`Veeam Kasten Veeam Kasten provides data protection and mobility for applications running on Red Hat OpenShift and offers many benefits:
+Kubernetes-native - Veeam Kasten is GitOps-ready and not dependent on external, legacy backup infrastructure Easy of Use - Full user interface and enterprise support Immutable Backups - Supported with AWS S3, Azure Blob, Google Cloud Storage, and S3-compliant solutions supporting Object Lock Blueprints - Orchestration framework for producing data consistent backups Transforms - Enabling mobility across clusters by allowing transformation of manifest details during restore operations Velocity - Bi-weekly releases of Veeam Kasten enable rapid support of new versions of OpenShift, security patches, and continuous innovation Veeam Kasten also features robust support for OpenShift Virtualization workloads, including the ability to perform export incremental backups of raw block mode PVCs. Block mode PVCs are common for OpenShift Virtualization deployments as they provide the best performance with least overhead for VMs, and more importantly can be configured in ReadWriteMany (RWX) access mode on many SAN platforms. ReadWriteMany access mode is required for VMs to enable live migration between nodes, a must-have capability for any production environment.
+Getting Started If you are unfamiliar with Veeam Kasten, follow the steps below to access and explore the Dashboard user interface.
+Logging In In the OpenShift Console, open Networking &gt; Routes.
+Under All Projects or kasten-io, open the URL for k10-route in a separate browser tab.
+If prompted, click Allow Selected Permissions to authorize Kasten to read account details from the OpenShift OAuth server.
+You will be logged in to the Kasten Dashboard as the currently authenticated OpenShift console user.
+NOTE: Unless the current user account has cluster-admin privileges, additional privileges are required. The example below can be used to add an IDP user group to the existing kasten-io-k10-k10-admin and kasten-io-k10-k10-ns-admin bindings. See Kasten documentation for complete details.
+oc patch clusterrolebinding kasten-io-k10-k10-admin \\ --type=&#39;json&#39; \\ --patch=&#39;[{&#34;op&#34;: &#34;add&#34;, &#34;path&#34;: &#34;/subjects/1&#34;, &#34;value&#34;: {&#34;kind&#34;: &#34;Group&#34;, &#34;name&#34;: &#34;admin-security-group-name&#34;} }]&#39; oc patch rolebinding kasten-io-k10-k10-ns-admin \\ --namespace kasten-io \\ --type=&#39;json&#39; \\ --patch=&#39;[{&#34;op&#34;: &#34;add&#34;, &#34;path&#34;: &#34;/subjects/1&#34;, &#34;value&#34;: {&#34;kind&#34;: &#34;Group&#34;, &#34;name&#34;: &#34;admin-security-group-name&#34;} }]&#39; Tour Dashboard The Dashboard landing page provides high level visibility into Veeam Kasten operations for the cluster. The Applications card indicates which applications (aka Kubernetes namespaces) are compliant or non-compliant with any configured policies, making it simple to identify if there are any lapses in protection. The Activity section provides a real time view of on-going or completed operations such as a policy runs or restores, and each can be selected to display additional levels of operational detail.
+Applications Selecting Applications either from the Dashboard card or from the sidebar will load a table representing the namespaces available on the cluster. This view provides visibility into data protection compliance, as well as the ability to perform actions relevant to a namespace, including ad-hoc backup, export, and restore operations, or creating a new policy.
+Location Profiles Select Location &gt; Profiles from the sidebar. Location Profiles define external storage targets for exporting backup data. Veeam Kasten can support exporting to multiple types of storage, including AWS S3, S3-compliant, Azure Blob, Google Cloud Storage, and NFS.
+Policies Select Policies &gt; Policies from the sidebar. Policies primarily define which resources to protect, frequency, retention, and which Location Profile to use for exporting data. Policies can also be used to automate importing and restoring backups from another cluster (i.e. for DR or testing).
+Operations Demos Below are supplemental demos that can be followed to become familiar with basic Veeam Kasten operations, including restoring VMs and manually creating additional policies.
+Manual Policy Run The Kasten policy applied to the edge-gitops-vms namespace by the pattern is configured to perform daily backups within a specified time window. As such, a run of this policy may not have be completed immediately following pattern deployment.
+From the Kasten Dashboard, select Policies &gt; Policies from the sidebar.
+Under the edge-gitops-vms-backup Policy, click Run Once &gt; Yes, Continue to initiate a manual run of the policy.
+It&rsquo;s recommended to specify an expiration date for manual runs as these backups are not subject to the retention configuration defined in the policy.
+Return to the Dashboard and click the policy run under Actions to monitor progress. Restoring VMs Once the edge-gitops-vms-backup has been completed at least once successfully, follow the steps below to test restoring an individual VM.
+From a terminal, force stop and delete the rhel8-kiosk-001 VM: oc patch virtualmachine -n edge-gitops-vms rhel8-kiosk-001 --type merge -p &#39;{&#34;spec&#34;:{&#34;running&#34;: false}}&#39; oc delete virtualmachine -n edge-gitops-vms rhel8-kiosk-001 NOTE: Veeam Kasten will terminate the existing workload during a restore operation, however the base image used for the rhel8-kiosk-... VMs does not include qemu tools, which will stall terminating the resource while it waits for a graceful VM shutdown.
+From the OpenShift Console, under Virtualization &gt; VirtualMachines, validate that rhel8-kiosk-001 no longer appears in the edge-gitops-vm namespace. From the Kasten Dashboard, select Applications from the sidebar.
+Under the edge-gitops-vms namespace, select Restore.
+Expand the most recent available restore point and select the EXPORTED option to restore from S3. Under Artifacts, click Deselect All Artifacts and, under Snapshot, select the rhel8-kiosk-001 PVC as shown. Under Spec, scroll down and select the rhel8-kiosk-001 VirtualMachine manifest and click Restore &gt; Restore. Return to the Dashboard and select the restore under Actions to monitor progress. Once the operation completes, return to the OpenShift Console and validate the rhel8-kiosk-001 VM is running. Creating Policies While a Validated Pattern user isn&rsquo;t likely to create or manage policies via the UI - it may be beneficial to mock up policies in the UI to extract the generated YAML manifest to adapt for GitOps-driven management.
+Create a new namespace, demo, from the terminal or OpenShift Console.
+From the OpenShift Console, under Virtualization &gt; VirtualMachines, select the demo Project and click Create VirtualMachine &gt; From InstanceType.
+Select the centos-stream9 boot volume and keep the remaining default settings, click Create VirtualMachine. Wait for the VM to reach a Running state.
+Note the PVC used by the VM is using Block volume mode to enable ReadWriteMany access to the volume, which in turn enables Live Migration of VMs between nodes. However Live Migration will not be available in the test environment if only a single baremetal node is available. From the Kasten Dashboard, under Policies &gt; Policies, click Create New Policy. Provide a Name (ex. demo-backup).
+Select the desired Backup Frequency.
+If desired, explore the Advanced Frequency and Backup Window options. Advanced Frequency settings allow the specification of exactly when a policy should run, and which backups should be promoted for retention (i.e. Keeping the Sunday daily backup as the Weekly for a given week). Backup Window ensures that data protection operations can only be performed during the specified window, and also allows for automated staggering of policy run start times to minimize impact on compute and storage resources.
+Toggle Enable Backups via Snapshot Exports and select your default-location-profile as the Export Location Profile. Under Select Applications, click By Name and specify the demo namespace as shown. Click Create Policy.
+Click Run Once &gt; Yes, Continue for the new policy.
+Return to the Dashboard and select the policy run under Actions to monitor progress. Once complete, the demo application will appear as Compliant as it currently fulfills the SLA defined in its policy. Next Steps See Ideas for Customization for information on how this pattern can be further extended. Help &amp; Feedback Report Bugs `,url:"https://validatedpatterns.io/patterns/ansible-edge-gitops-kasten/veeam-kasten/",breadcrumb:"/patterns/ansible-edge-gitops-kasten/veeam-kasten/"},"https://validatedpatterns.io/patterns/multicloud-gitops-amx-rhoai/mcg-amx-rhoai-cluster-sizing/":{title:"Cluster sizing",tags:[],content:` About OpenShift cluster sizing for the Intel AMX accelerated Multicloud GitOps pattern The minimum requirements for an OpenShift Container Platform cluster depend on your installation platform, for example:
+For AWS, see Installing OpenShift Container Platform on AWS.
+For bare-metal, see Installing OpenShift Container Platform on bare metal.
+To understand cluster sizing requirements for the Intel AMX accelerated Multicloud GitOps pattern with Openshift AI, consider the following components that the pattern deploys on the datacenter or the hub OpenShift cluster:
+Name Kind Namespace Description multicloud-gitops-amx-rhoai-hub
+Application
+multicloud-gitops-amx-rhoai-hub
+Hub GitOps management
+Red Hat Advanced Cluster Management
+Operator
+open-cluster-management
+Advance Cluster Management
+Red Hat OpenShift GitOps
+Operator
+openshift-operators
+OpenShift GitOps
+Node Feature Discovery
+Operator
+openshift-nfd
+Manages the detection and labeling of hardware features and configuration (for example Intel AMX)
+Red Hat OpenShift Data Foundation
+Operator
+openshift-storage
+Cloud Native storage solution
+The Intel AMX accelerated Multicloud GitOps pattern with Openshift AI also includes the Red Hat Advanced Cluster Management (RHACM) supporting operator that is installed by OpenShift GitOps using Argo CD.
+Intel AMX accelerated Multicloud GitOps pattern with Openshift AI with OpenShift clusters sizes The datacenter hub OpenShift cluster needs to be a bit bigger than the Factory/Edge clusters because this is where the developers will be running pipelines to build and deploy the Intel AMX accelerated Multicloud GitOps pattern with Openshift AI on the cluster. The above cluster sizing is close to a minimum size for a Datacenter HUB cluster. In the next few sections we take some snapshots of the cluster utilization while the Intel AMX accelerated Multicloud GitOps pattern with Openshift AI is running. Keep in mind that resources will have to be added as more developers are working building their applications.
+The recommended clusters sizes for datacenter hub and for managed datacenter are the same in this case:
+Node type Number of nodes CPU Memory Storage Control Planes
+3
+2x 5th Generation Intel Xeon Gold 6526Y (16 cores at 2.8 GHz base with Intel AMX) or better
+128 GB (8 x 16 GB DDR5 4800) or more
+NVME SSD 3TB or more
+Workers
+3
+2x 5th Generation Intel Xeon Gold 6538Y+ (32 cores at 2.2 GHz base with Intel AMX) or better
+256 GB (16 x 16 GB) or 512 GB (16 x 32GB) DDR5-4800
+NVME SSD 3TB or more
+You might want to add resources when more developers are working on building their applications.
+The pattern was tested in the on-premises environment with following hardware configuration (per cluster):
+Node type Number of nodes CPU Memory Storage Control Planes + Workers
+3 + 3
+2x 5th Generation Intel Xeon Platinum 8568Y+ (48 cores at 2.3 GHz base with Intel AMX)
+512 GB (16x32GB DDR5 5600)
+4x 3.84TB U.2 NVMe PCIe Gen4
+`,url:"https://validatedpatterns.io/patterns/multicloud-gitops-amx-rhoai/mcg-amx-rhoai-cluster-sizing/",breadcrumb:"/patterns/multicloud-gitops-amx-rhoai/mcg-amx-rhoai-cluster-sizing/"},"https://validatedpatterns.io/patterns/medical-diagnosis/demo-script/":{title:"Demo Script",tags:[],content:` Introduction The medical diagnosis pattern integrates multiple Red Hat and Open Source technologies together to create an AI/ML workflow that is able to identify signs of pneumonia in x-ray images. Within this demo a dashboard is automatically created that provides the CPU and Memory metrics for the pod running the risk assessment application. The dashboard also provides visual representation of the AI/ML workflow from the images being generated at the remote medical facility to running through the image anonymizer, it also includes the image being scanned along with statistics from the workflow - indicating the probability in which a patient may or may not have pneumonia.
+We simulate the function of the remote medical facility with an application called image-generator
+Objectives In this demo you will complete the following:
+Prepare your local workstation
+Update the pattern repo with your cluster values
+Deploy the pattern
+Access the dashboard
+Getting Started Follow the Getting Started Guide to ensure that you have met all of the pre-requisites
+Review Preparing for Deployment for updating the pattern with your cluster values
+This demo begins after ./pattern.sh make install has been executed
+Demo Now that we have deployed the pattern onto our cluster, we can begin to discover what has changed, and then move onto the dashboard.
+Administrator View - Review Changes to cluster Login to your cluster’s console with the kubeadmin user
+Let’s check out what operators were installed - In the accordion menu on the left:
+click Operators
+click Installed Operators
+Ensure that All Projects is selected
+If you started with a new cluster then there were no layered products or operators installed. With the Validated Patterns framework we describe or declare what our cluster’s desired state is and the GitOps engine does the rest. This includes creating the instance of the operator and any additional configuration between other API’s to ensure everything is working together nicely.
+Developer View - Review Changes to cluster Let’s switch to the developer context by click on Administrator in the top left corner of the accordion menu then click Developer
+Change projects to xraylab-1
+Click on Topology
+Look at all of the resources that have been created for this demo application. What we see in this interface is the collection of all components required for this AI/ML workflow to properly execute. There are even more resources and configurations that get deployed but because we don’t directly interact with them we won’t worry too much about them. The take away here is when you utilize the framework you are able to build in automation just like this which allows your developers to focus on their important developer things.
+Invalid Certificates We are deploying this demo using self-signed certificates that are untrusted by our browser. Unless you have provisioned valid certificates for your OpenShift cluster you must accept the invalid certificates for:
+image-server | xraylab-1 namespace
+s3-rgw | openshift-storage namespace
+grafana | xraylab-1 namespace
+IMAGESERVER_ROUTE=https://$(oc get route -n xraylab-1 image-server -o jsonpath=&#39;{.spec.host}&#39;) echo $IMAGESERVER_ROUTE S3RGW_ROUTE=https://$(oc get route -n openshift-storage s3-rgw -o jsonpath=&#39;{.spec.host}&#39;) echo $S3RGW_ROUTE GRAFANA_ROUTE=https://$(oc get route -n xraylab-1 grafana -o jsonpath=&#39;{.spec.host}&#39;) echo $GRAFANA_ROUTE You must accept the security risks / self signed certificates before scaling the image-generator application
+Scale up the deployment As we mentioned earlier, we don’t have an x-ray machine hanging around that we can use for this demo, so we emulate one by creating an s3 bucket and hosting the x-ray images within it. In the &#34;real world&#34; an x-ray would be taken at an edge medical facility and then uploaded to an OpenShift Data Foundations (ODF) S3 compatible bucket in the Core Hospital, triggering the AI/ML workflow.
+To emulate the edge medical facility we use an application called image-generator which (when scaled up) will download the x-rays from s3 and put them in an ODF s3 bucket in the cluster, triggering the AI/ML workflow.
+Let’s scale the image-generator deploymentConfig up to start the pipeline
+Make sure that you are in the xraylab-1 project under the Developer context in the OpenShift Console
+In the Topology menu under the Developer context in the OpenShift Console:
+Search for the image-generator application in the Topology console
+Click on the image-generator application ( you may have to zoom in on the highlighted application)
+Switch to the Details menu in the application menu context
+Click the ^ next to the pod donut
+Demo Dashboard Now let’s jump over to the dashboard
+Return to the topology screen
+Select “Grafana” in the drop down for Filter by resource
+Click the grafana icon
+Open url to go open a browser for the grafana dashboard.
+Within the grafana dashboard:
+click the dashboards icon
+click Manage
+select xraylab-1
+finally select the XRay Lab folder
+In the dashboard on the right we see the images that have been uploaded, processed and anonymized. Images in the processed view have been through the AI/ML pipeline and images in the lower third are images that have been stripped of Personally Identifiable Information or PII.
+In the lower middle section of the dashboard we can see the distribution of images that are normal, unsure or pneumonia has been detected. We can also see the number of risk assessment containers running as well as the cpu and memory metrics for the pods.
+Summary You did it! You have completed the deployment of the medical diagnosis pattern! Hopefully you are getting ideas of how you can take advantage of our GitOps framework to deploy and manage your applications.
+The medical diagnosis pattern is more than just the identification and detection of pneumonia in x-ray images. It is an object detection and classification model built on top of Red Hat OpenShift and can be transformed to fit multiple use-cases within the object classification paradigm. Similar use-cases would be detecting contraband items in the Postal Service or even in luggage in an airport baggage scanner.
+For more information on Validated Patterns visit our website
+`,url:"https://validatedpatterns.io/patterns/medical-diagnosis/demo-script/",breadcrumb:"/patterns/medical-diagnosis/demo-script/"},"https://validatedpatterns.io/patterns/multicloud-gitops-sgx/mcg-sgx-demo-script/":{title:"Demo Script",tags:[],content:` Introduction The multicloud gitops pattern is designed to be an entrypoint into the Validated Patterns framework. Demo, accessible within the pattern, contains two applications config-demo and hello-world to show the basic configuration and execution examples. For more information on Validated Patterns visit our documentation site.
+Objectives In this demo you will complete the following:
+Prepare your local workstation
+Deploy the pattern
+Extend the pattern with a small tweak
+Getting Started Make sure you have met all the installation prerequisites
+Follow the Getting Started Guide to ensure that you have met all of the prerequisites
+This demo begins after ./pattern.sh make install has been executed
+Demo Now that we have deployed the pattern onto our cluster, with origin pointing to your fork and using my-branch as the name of the used branch, we can begin to discover what has happened. You should be able to click on the nine-box and see the following entries:
+If you now click on the &#34;Hub ArgoCD&#34; menu entry you will be taken to the ArgoCD instance with all the applications.
+Secrets loading By default in the MultiCloud GitOps pattern the secrets get loaded automatically via an out of band process inside the vault running in the OCP cluster. This means that running ./pattern.sh make install will also call the load-secrets makefile target. This load-secrets target will look for a yaml file describing the secrets to be loaded into vault and in case it cannot find one it will use the values-secret.yaml.template file in the git repo to try and generate random secrets.
+Let’s copy the template to our home folder and reload the secrets:
+cp ./values-secret.yaml.template ~/values-secret-multicloud-gitops.yaml ./pattern.sh make load-secrets At this point if the config-demo application was not green already it should become green in the ArgoCD user interface.
+Verify the test web pages If you now click on the Routes in the Networking menu entry you will see the following network routes:
+Clicking on the hello-world application should show a small demo app that prints &#34;Hello World!&#34;:
+Once the secrets are loaded correctly inside the vault, clicking on the config-demo route should display a small application where said secret is shown:
+Make a small change to the test web pages Now we can try and tweak the hello-world application and add the below line in the charts/all/hello-world/templates/hello-world-cm.yaml file:
+diff --git a/charts/all/hello-world/templates/hello-world-cm.yaml b/charts/all/hello-world/templates/hello-world-cm.yaml index e59561ca..bd416bc6 100644 --- a/charts/all/hello-world/templates/hello-world-cm.yaml +++ b/charts/all/hello-world/templates/hello-world-cm.yaml @@ -14,6 +14,7 @@ data: &lt;/head&gt; &lt;body&gt; &lt;h1&gt;Hello World!&lt;/h1&gt; + &lt;h1&gt;This is a patched version via git&lt;/h1&gt; &lt;br/&gt; &lt;h2&gt; Hub Cluster domain is &#39;{{ .Values.global.hubClusterDomain }}&#39; &lt;br&gt; Once we commit the above change via git commit -a -m &#34;test a change&#34; and run git push origin my-branch we will be able to observe argo applying the above change:
+Summary You did it! You have completed the deployment of the MultiCloud GitOps pattern and you made a small local change and applied it via GitOps! Hopefully you are getting ideas of how you can take advantage of our GitOps framework to deploy and manage your applications.
+For more information on Validated Patterns visit our website
+`,url:"https://validatedpatterns.io/patterns/multicloud-gitops-sgx/mcg-sgx-demo-script/",breadcrumb:"/patterns/multicloud-gitops-sgx/mcg-sgx-demo-script/"},"https://validatedpatterns.io/patterns/multicloud-gitops/mcg-demo-script/":{title:"Demo Script",tags:[],content:` Introduction The multicloud gitops pattern is designed to be an entrypoint into the Validated Patterns framework. For more information on Validated Patterns visit our documentation site
+Objectives In this demo you will complete the following:
+Prepare your local workstation
+Deploy the pattern
+Extend the pattern with a small tweak
+Getting Started Make sure you have met all the installation prerequisites
+Follow the Getting Started Guide to ensure that you have met all of the prerequisites
+This demo begins after ./pattern.sh make install has been executed
+Demo Now that we have deployed the pattern onto our cluster, with origin pointing to your fork and using my-branch as the name of the used branch, we can begin to discover what has happened. You should be able to click on the nine-box and see the following entries:
+If you now click on the &#34;Hub ArgoCD&#34; menu entry you will be taken to the ArgoCD instance with all the applications.
+Secrets loading By default in the MultiCloud GitOps pattern the secrets get loaded automatically via an out of band process inside the vault running in the OCP cluster. This means that running ./pattern.sh make install will also call the load-secrets makefile target. This load-secrets target will look for a yaml file describing the secrets to be loaded into vault and in case it cannot find one it will use the values-secret.yaml.template file in the git repo to try and generate random secrets.
+Let’s copy the template to our home folder and reload the secrets:
+cp ./values-secret.yaml.template ~/values-secret-multicloud-gitops.yaml ./pattern.sh make load-secrets At this point if the config-demo application was not green already it should become green in the ArgoCD user interface.
+Verify the test web pages If you now click on the Routes in the Networking menu entry you will see the following network routes:
+Clicking on the hello-world application should show a small demo app that prints &#34;Hello World!&#34;:
+Once the secrets are loaded correctly inside the vault, clicking on the config-demo route should display a small application where said secret is shown:
+Make a small change to the test web pages Now we can try and tweak the hello-world application and add the below line in the charts/all/hello-world/templates/hello-world-cm.yaml file:
+diff --git a/charts/all/hello-world/templates/hello-world-cm.yaml b/charts/all/hello-world/templates/hello-world-cm.yaml index e59561ca..bd416bc6 100644 --- a/charts/all/hello-world/templates/hello-world-cm.yaml +++ b/charts/all/hello-world/templates/hello-world-cm.yaml @@ -14,6 +14,7 @@ data: &lt;/head&gt; &lt;body&gt; &lt;h1&gt;Hello World!&lt;/h1&gt; + &lt;h1&gt;This is a patched version via git&lt;/h1&gt; &lt;br/&gt; &lt;h2&gt; Hub Cluster domain is &#39;{{ .Values.global.hubClusterDomain }}&#39; &lt;br&gt; Once we commit the above change via git commit -a -m &#34;test a change&#34; and run git push origin my-branch we will be able to observe argo applying the above change:
+Summary You did it! You have completed the deployment of the MultiCloud GitOps pattern and you made a small local change and applied it via GitOps! Hopefully you are getting ideas of how you can take advantage of our GitOps framework to deploy and manage your applications.
+For more information on Validated Patterns visit our website
+`,url:"https://validatedpatterns.io/patterns/multicloud-gitops/mcg-demo-script/",breadcrumb:"/patterns/multicloud-gitops/mcg-demo-script/"},"https://validatedpatterns.io/patterns/travelops/demo-script/":{title:"Demo Script",tags:[],content:` TravelOps Demo Script TravelOps demo script is under construction. Will be posted shortly.
+`,url:"https://validatedpatterns.io/patterns/travelops/demo-script/",breadcrumb:"/patterns/travelops/demo-script/"},"https://validatedpatterns.io/patterns/multicloud-gitops-amx/mcg-amx-ideas-for-customization/":{title:"Ideas for customization",tags:[],content:` Ideas for customization About customizing the pattern Multicloud GitOps pattern One of the major goals of the Validated Patterns development process is to create modular, customizable demos. The Multicloud Gitops is just an example of a pattern managing multiple clusters in a GitOps fashion. It contains a very simple config-demo application, which prints out a secret that was injected into the vault through an out-of-band mechanism.
+You can customize this demo in different ways.
+Split the config-demo across hub and regional clusters Currently hub and regional clusters are reusing the exact same helm chart found at charts/all/config-demo. The first customization step could be to split the demo app in two separate charts: one in charts/hub/config-demo and one in charts/region/config-demo. Once charts/all/config-demo has been copied to charts/hub/config-demo and charts/region/config-demo, you need to include them in the respective values-hub.yaml and values-region-one.yaml, respectively.
+After completing this configuration, you can start customizing the two apps and make them output a different web page entirely depending if the pod is running on the hub or on the cluster.
+Rest API addition After splitting the charts, you could implement a small REST API server on the hub. This API could serve read-only values out to anyone and could provide some update write-APIs only if the client provides a secret, for example, by using the X-API-KEY mechanism. You can tweak the config-demo application to communicate to the hub and use a vault-injected secret as the X-API-KEY. So the hub would possess the key through the External-Secrets generated kubernetes secret and the regional app would possess that same secret via the RHACM policy pushing out secrets via the {{hub fromSecret}} mechanism.
+`,url:"https://validatedpatterns.io/patterns/multicloud-gitops-amx/mcg-amx-ideas-for-customization/",breadcrumb:"/patterns/multicloud-gitops-amx/mcg-amx-ideas-for-customization/"},"https://validatedpatterns.io/patterns/multicloud-gitops-qat/mcg-qat-ideas-for-customization/":{title:"Ideas for customization",tags:[],content:` Ideas for customization About customizing the pattern Multicloud GitOps pattern One of the major goals of the Validated Patterns development process is to create modular, customizable demos. The Multicloud Gitops is just an example of a pattern managing multiple clusters in a GitOps fashion. It contains a very simple config-demo application, which prints out a secret that was injected into the vault through an out-of-band mechanism.
+You can customize this demo in different ways.
+Split the config-demo across hub and regional clusters Currently hub and regional clusters are reusing the exact same helm chart found at charts/all/config-demo. The first customization step could be to split the demo app in two separate charts: one in charts/hub/config-demo and one in charts/region/config-demo. Once charts/all/config-demo has been copied to charts/hub/config-demo and charts/region/config-demo, you need to include them in the respective values-hub.yaml and values-region-one.yaml, respectively.
+After completing this configuration, you can start customizing the two apps and make them output a different web page entirely depending if the pod is running on the hub or on the cluster.
+Rest API addition After splitting the charts, you could implement a small REST API server on the hub. This API could serve read-only values out to anyone and could provide some update write-APIs only if the client provides a secret, for example, by using the X-API-KEY mechanism. You can tweak the config-demo application to communicate to the hub and use a vault-injected secret as the X-API-KEY. So the hub would possess the key through the External-Secrets generated kubernetes secret and the regional app would possess that same secret via the RHACM policy pushing out secrets via the {{hub fromSecret}} mechanism.
+`,url:"https://validatedpatterns.io/patterns/multicloud-gitops-qat/mcg-qat-ideas-for-customization/",breadcrumb:"/patterns/multicloud-gitops-qat/mcg-qat-ideas-for-customization/"},"https://validatedpatterns.io/patterns/multicloud-gitops-sgx-hello-world/mcg-sgx-hello-world-ideas-for-customization/":{title:"Ideas for customization",tags:[],content:` Ideas for customization About customizing the pattern Multicloud GitOps pattern One of the major goals of the Validated Patterns development process is to create modular, customizable demos. The Multicloud Gitops is just an example of a pattern managing multiple clusters in a GitOps fashion. It contains a very simple config-demo application, which prints out a secret that was injected into the vault through an out-of-band mechanism.
+You can customize this demo in different ways.
+Split the config-demo across hub and regional clusters Currently hub and regional clusters are reusing the exact same helm chart found at charts/all/config-demo. The first customization step could be to split the demo app in two separate charts: one in charts/hub/config-demo and one in charts/region/config-demo. Once charts/all/config-demo has been copied to charts/hub/config-demo and charts/region/config-demo, you need to include them in the respective values-hub.yaml and values-region-one.yaml, respectively.
+After completing this configuration, you can start customizing the two apps and make them output a different web page entirely depending if the pod is running on the hub or on the cluster.
+Rest API addition After splitting the charts, you could implement a small REST API server on the hub. This API could serve read-only values out to anyone and could provide some update write-APIs only if the client provides a secret, for example, by using the X-API-KEY mechanism. You can tweak the config-demo application to communicate to the hub and use a vault-injected secret as the X-API-KEY. So the hub would possess the key through the External-Secrets generated kubernetes secret and the regional app would possess that same secret via the RHACM policy pushing out secrets via the {{hub fromSecret}} mechanism.
+`,url:"https://validatedpatterns.io/patterns/multicloud-gitops-sgx-hello-world/mcg-sgx-hello-world-ideas-for-customization/",breadcrumb:"/patterns/multicloud-gitops-sgx-hello-world/mcg-sgx-hello-world-ideas-for-customization/"},"https://validatedpatterns.io/patterns/multicloud-gitops-sgx/mcg-sgx-ideas-for-customization/":{title:"Ideas for customization",tags:[],content:` Ideas for customization About customizing the pattern Multicloud GitOps pattern One of the major goals of the Validated Patterns development process is to create modular, customizable demos. The Multicloud Gitops is just an example of a pattern managing multiple clusters in a GitOps fashion. It contains a very simple config-demo application, which prints out a secret that was injected into the vault through an out-of-band mechanism.
+You can customize this demo in different ways.
+Split the config-demo across hub and regional clusters Currently hub and regional clusters are reusing the exact same helm chart found at charts/all/config-demo. The first customization step could be to split the demo app in two separate charts: one in charts/hub/config-demo and one in charts/region/config-demo. Once charts/all/config-demo has been copied to charts/hub/config-demo and charts/region/config-demo, you need to include them in the respective values-hub.yaml and values-region-one.yaml, respectively.
+After completing this configuration, you can start customizing the two apps and make them output a different web page entirely depending if the pod is running on the hub or on the cluster.
+Rest API addition After splitting the charts, you could implement a small REST API server on the hub. This API could serve read-only values out to anyone and could provide some update write-APIs only if the client provides a secret, for example, by using the X-API-KEY mechanism. You can tweak the config-demo application to communicate to the hub and use a vault-injected secret as the X-API-KEY. So the hub would possess the key through the External-Secrets generated kubernetes secret and the regional app would possess that same secret via the RHACM policy pushing out secrets via the {{hub fromSecret}} mechanism.
+`,url:"https://validatedpatterns.io/patterns/multicloud-gitops-sgx/mcg-sgx-ideas-for-customization/",breadcrumb:"/patterns/multicloud-gitops-sgx/mcg-sgx-ideas-for-customization/"},"https://validatedpatterns.io/patterns/multicloud-gitops/mcg-ideas-for-customization/":{title:"Ideas for customization",tags:[],content:`Ideas for customization About customizing the pattern Multicloud GitOps pattern One of the major goals of the Validated Patterns development process is to create modular, customizable demos. The Multicloud Gitops is just an example of a pattern managing multiple clusters in a GitOps fashion. It contains a very simple config-demo application, which prints out a secret that was injected into the vault through an out-of-band mechanism.
+You can customize this demo in different ways.
+Split the config-demo across hub and regional clusters Currently hub and regional clusters are reusing the exact same helm chart found at charts/all/config-demo. The first customization step could be to split the demo app in two separate charts: one in charts/hub/config-demo and one in charts/region/config-demo. Once charts/all/config-demo has been copied to charts/hub/config-demo and charts/region/config-demo, you need to include them in the respective values-hub.yaml and values-region-one.yaml, respectively.
+After completing this configuration, you can start customizing the two apps and make them output a different web page entirely depending if the pod is running on the hub or on the cluster.
+Rest API addition After splitting the charts, you could implement a small REST API server on the hub. This API could serve read-only values out to anyone and could provide some update write-APIs only if the client provides a secret, for example, by using the X-API-KEY mechanism. You can tweak the config-demo application to communicate to the hub and use a vault-injected secret as the X-API-KEY. So the hub would possess the key through the External-Secrets generated kubernetes secret and the regional app would possess that same secret via the RHACM policy pushing out secrets via the {{hub fromSecret}} mechanism.
+`,url:"https://validatedpatterns.io/patterns/multicloud-gitops/mcg-ideas-for-customization/",breadcrumb:"/patterns/multicloud-gitops/mcg-ideas-for-customization/"},"https://validatedpatterns.io/patterns/ansible-edge-gitops-kasten/ideas-for-customization/":{title:"Ideas for Customization",tags:[],content:`Ideas for Customization Why change it? One of the major goals of the Red Hat patterns development process is to create modular, customizable demos. Maybe you are not interested in Ignition as an application, or you do not have kiosks&hellip;but you do have other use cases that involve running containers on edge devices. Maybe you want to experiment with different releases of RHEL, or you want to do something different with Ansible Automation Platform.
+This demo in particular can be customized in a number of ways that might be very interesting - and here are some starter ideas with some instructions on exactly what and where changes would need to be made in the pattern to accommodate those changes.
+HOWTO define your own VM sets using the chart Either fork the repo or copy the edge-gitops-vms chart out of it.
+Customize the values.yaml file
+The vms data structure is designed to support multiple groups and types of VMs. The kiosk example defines all of the variables currently supported by the chart, including references to the Vault instance and port definitions. If, for example, you wanted to replace kiosk with new iotsensor and iotgateway types, the whole file might look like this:
+--- secretStore: name: vault-backend kind: ClusterSecretStore cloudInit: defaultUser: &#39;cloud-user&#39; defaultPassword: &#39;6toh-n1d5-9xpq&#39; vms: iotsensor: count: 4 flavor: small workload: server os: rhel8 role: iotgateway storage: 20Gi memory: 2Gi cores: 1 sockets: 1 threads: 1 cloudInitUser: cloud-user cloudInitPassword: 6toh-n1d5-9xpq template: rhel8-server-small sshsecret: secret/data/hub/iotsensor-ssh sshpubkeyfield: publickey ports: - name: ssh port: 22 protocol: TCP targetPort: 22 iotgateway: count: 1 flavor: medium workload: server os: rhel8 role: iotgateway storage: 30Gi memory: 4Gi cores: 1 sockets: 1 threads: 1 cloudInitUser: cloud-user cloudInitPassword: 6toh-n1d5-9xpq template: rhel8-server-medium sshsecret: secret/data/hub/iotgateway-ssh sshpubkeyfield: publickey ports: - name: ssh port: 22 protocol: TCP targetPort: 22 - name: mqtt port: 1883 protocol: TCP targetPort: 1883 This would create 1 iotgateway VM and 4 iotsensor VMs. Adjustments would also need to be made in values-secret and ansible-load-controller to add the iotgateway-ssh and iotsensor-ssh data structures.
+HOWTO define your own VM sets &ldquo;from scratch&rdquo; Pick a default template from the standard OpenShift Virtualization template library in the openshift namespace. For this pattern, we used rhel8-desktop-medium: $ oc get template -n openshift rhel8-desktop-medium NAME DESCRIPTION PARAMETERS OBJECTS rhel8-desktop-medium Template for Red Hat Enterprise Linux 8 VM or newer. A PVC with the RHEL disk... 4 (2 generated) 1 It might help to create a VM through the command line template process, and see what objects OpenShift Virtualization creates to bring that VM up: To see the actual JSON that the template converts into:
+$ oc process -n openshift rhel8-desktop-medium { &#34;kind&#34;: &#34;List&#34;, &#34;apiVersion&#34;: &#34;v1&#34;, &#34;metadata&#34;: {}, &#34;items&#34;: [ { &#34;apiVersion&#34;: &#34;kubevirt.io/v1&#34;, &#34;kind&#34;: &#34;VirtualMachine&#34;, &#34;metadata&#34;: { &#34;annotations&#34;: { &#34;vm.kubevirt.io/validations&#34;: &#34;[\\n {\\n \\&#34;name\\&#34;: \\&#34;minimal-required-memory\\&#34;,\\n \\&#34;path\\&#34;: \\&#34;jsonpath::.spec.domain.resources.requests.memory\\&#34;,\\n \\&#34;rule\\&#34;: \\&#34;integer\\&#34;,\\n \\&#34;message\\&#34;: \\&#34;This VM requires more memory.\\&#34;,\\n \\&#34;min\\&#34;: 1610612736\\n }\\n]\\n&#34; }, &#34;labels&#34;: { &#34;app&#34;: &#34;rhel8-yywa22lijw8hl017&#34;, &#34;vm.kubevirt.io/template&#34;: &#34;rhel8-desktop-medium&#34;, &#34;vm.kubevirt.io/template.revision&#34;: &#34;1&#34;, &#34;vm.kubevirt.io/template.version&#34;: &#34;v0.19.5&#34; }, &#34;name&#34;: &#34;rhel8-yywa22lijw8hl017&#34; }, &#34;spec&#34;: { &#34;dataVolumeTemplates&#34;: [ { &#34;apiVersion&#34;: &#34;cdi.kubevirt.io/v1beta1&#34;, &#34;kind&#34;: &#34;DataVolume&#34;, &#34;metadata&#34;: { &#34;name&#34;: &#34;rhel8-yywa22lijw8hl017&#34; }, &#34;spec&#34;: { &#34;sourceRef&#34;: { &#34;kind&#34;: &#34;DataSource&#34;, &#34;name&#34;: &#34;rhel8&#34;, &#34;namespace&#34;: &#34;openshift-virtualization-os-images&#34; }, &#34;storage&#34;: { &#34;resources&#34;: { &#34;requests&#34;: { &#34;storage&#34;: &#34;30Gi&#34; } } } } } ], &#34;running&#34;: false, &#34;template&#34;: { &#34;metadata&#34;: { &#34;annotations&#34;: { &#34;vm.kubevirt.io/flavor&#34;: &#34;medium&#34;, &#34;vm.kubevirt.io/os&#34;: &#34;rhel8&#34;, &#34;vm.kubevirt.io/workload&#34;: &#34;desktop&#34; }, &#34;labels&#34;: { &#34;kubevirt.io/domain&#34;: &#34;rhel8-yywa22lijw8hl017&#34;, &#34;kubevirt.io/size&#34;: &#34;medium&#34; } }, &#34;spec&#34;: { &#34;domain&#34;: { &#34;cpu&#34;: { &#34;cores&#34;: 1, &#34;sockets&#34;: 1, &#34;threads&#34;: 1 }, &#34;devices&#34;: { &#34;disks&#34;: [ { &#34;disk&#34;: { &#34;bus&#34;: &#34;virtio&#34; }, &#34;name&#34;: &#34;rhel8-yywa22lijw8hl017&#34; }, { &#34;disk&#34;: { &#34;bus&#34;: &#34;virtio&#34; }, &#34;name&#34;: &#34;cloudinitdisk&#34; } ], &#34;inputs&#34;: [ { &#34;bus&#34;: &#34;virtio&#34;, &#34;name&#34;: &#34;tablet&#34;, &#34;type&#34;: &#34;tablet&#34; } ], &#34;interfaces&#34;: [ { &#34;masquerade&#34;: {}, &#34;name&#34;: &#34;default&#34; } ], &#34;networkInterfaceMultiqueue&#34;: true, &#34;rng&#34;: {} }, &#34;machine&#34;: { &#34;type&#34;: &#34;pc-q35-rhel8.4.0&#34; }, &#34;resources&#34;: { &#34;requests&#34;: { &#34;memory&#34;: &#34;4Gi&#34; } } }, &#34;evictionStrategy&#34;: &#34;LiveMigrate&#34;, &#34;networks&#34;: [ { &#34;name&#34;: &#34;default&#34;, &#34;pod&#34;: {} } ], &#34;terminationGracePeriodSeconds&#34;: 180, &#34;volumes&#34;: [ { &#34;dataVolume&#34;: { &#34;name&#34;: &#34;rhel8-yywa22lijw8hl017&#34; }, &#34;name&#34;: &#34;rhel8-yywa22lijw8hl017&#34; }, { &#34;cloudInitNoCloud&#34;: { &#34;userData&#34;: &#34;#cloud-config\\nuser: cloud-user\\npassword: nnpa-12td-e0r7\\nchpasswd: { expire: False }&#34; }, &#34;name&#34;: &#34;cloudinitdisk&#34; } ] } } } } ] } And to use the template to create a VM:
+oc process -n openshift rhel8-desktop-medium | oc apply -f - virtualmachine.kubevirt.io/rhel8-q63yuvxpjdvy18l7 created In just a few minutes, you will have a blank rhel8 VM running, which you can then login to (via console) and customize.
+Get the details of this template as a local YAML file: oc get template -n openshift rhel8-desktop-medium -o yaml &gt; my-template.yaml Once you have this local template, you can view the elements you want to customize, possibly using this as an example.
+HOWTO Define your own Ansible Controller Configuration The ansible_load_controller.sh is designed to be relatively easy to customize with a new controller configuration. Structurally, it is principally based on configure_controller.yml from the Red Hat Community of Practice controller_configuration collection. The order and specific list of roles invoked is taken from there.
+To customize it, the main thing would be to replace the different variables in the role tasks with the your own. The script includes the roles for variable types that this pattern does not manage in order to make that part straightforward. Feel free to add your own roles and playbooks (and add them to the controller configuration script).
+The reason this pattern ships with a script as it does instead of invoking the referenced playbook directly is that several of the configuration elements depend on each other, and there was not a super-convenient place to put things like the controller credentials as the playbook suggests.
+HOWTO substitute your own container application (instead of ignition) Adjust the query in the inventory_preplay.yml either by overriding the vars for the play, or forking the repo and replacing the vars with your own query terms. (That is, use your own label(s) and namespace to discover the services you want to connect to.
+Adjust or override the vars in the provision_kiosk.yml playbook to suitable values for your own container application. The roles it calls are fairly generic, so changing the vars is all you should need to do.
+Next Steps Help &amp; Feedback Report Bugs `,url:"https://validatedpatterns.io/patterns/ansible-edge-gitops-kasten/ideas-for-customization/",breadcrumb:"/patterns/ansible-edge-gitops-kasten/ideas-for-customization/"},"https://validatedpatterns.io/patterns/ansible-edge-gitops/ideas-for-customization/":{title:"Ideas for Customization",tags:[],content:`Ideas for Customization Why change it? One of the major goals of the Red Hat patterns development process is to create modular, customizable demos. Maybe you are not interested in Ignition as an application, or you do not have kiosks&hellip;but you do have other use cases that involve running containers on edge devices. Maybe you want to experiment with different releases of RHEL, or you want to do something different with Ansible Automation Platform.
+This demo in particular can be customized in a number of ways that might be very interesting - and here are some starter ideas with some instructions on exactly what and where changes would need to be made in the pattern to accommodate those changes.
+HOWTO define your own VM sets using the chart Either fork the repo or copy the edge-gitops-vms chart out of it.
+Customize the values.yaml file
+The vms data structure is designed to support multiple groups and types of VMs. The kiosk example defines all of the variables currently supported by the chart, including references to the Vault instance and port definitions. If, for example, you wanted to replace kiosk with new iotsensor and iotgateway types, the whole file might look like this:
+--- secretStore: name: vault-backend kind: ClusterSecretStore cloudInit: defaultUser: &#39;cloud-user&#39; defaultPassword: &#39;6toh-n1d5-9xpq&#39; vms: iotsensor: count: 4 flavor: small workload: server os: rhel8 role: iotgateway storage: 20Gi memory: 2Gi cores: 1 sockets: 1 threads: 1 cloudInitUser: cloud-user cloudInitPassword: 6toh-n1d5-9xpq template: rhel8-server-small sshsecret: secret/data/hub/iotsensor-ssh sshpubkeyfield: publickey ports: - name: ssh port: 22 protocol: TCP targetPort: 22 iotgateway: count: 1 flavor: medium workload: server os: rhel8 role: iotgateway storage: 30Gi memory: 4Gi cores: 1 sockets: 1 threads: 1 cloudInitUser: cloud-user cloudInitPassword: 6toh-n1d5-9xpq template: rhel8-server-medium sshsecret: secret/data/hub/iotgateway-ssh sshpubkeyfield: publickey ports: - name: ssh port: 22 protocol: TCP targetPort: 22 - name: mqtt port: 1883 protocol: TCP targetPort: 1883 This would create 1 iotgateway VM and 4 iotsensor VMs. Adjustments would also need to be made in values-secret and ansible-load-controller to add the iotgateway-ssh and iotsensor-ssh data structures.
+HOWTO define your own VM sets &ldquo;from scratch&rdquo; Pick a default template from the standard OpenShift Virtualization template library in the openshift namespace. For this pattern, we used rhel8-desktop-medium: $ oc get template -n openshift rhel8-desktop-medium NAME DESCRIPTION PARAMETERS OBJECTS rhel8-desktop-medium Template for Red Hat Enterprise Linux 8 VM or newer. A PVC with the RHEL disk... 4 (2 generated) 1 It might help to create a VM through the command line template process, and see what objects OpenShift Virtualization creates to bring that VM up: To see the actual JSON that the template converts into:
+$ oc process -n openshift rhel8-desktop-medium { &#34;kind&#34;: &#34;List&#34;, &#34;apiVersion&#34;: &#34;v1&#34;, &#34;metadata&#34;: {}, &#34;items&#34;: [ { &#34;apiVersion&#34;: &#34;kubevirt.io/v1&#34;, &#34;kind&#34;: &#34;VirtualMachine&#34;, &#34;metadata&#34;: { &#34;annotations&#34;: { &#34;vm.kubevirt.io/validations&#34;: &#34;[\\n {\\n \\&#34;name\\&#34;: \\&#34;minimal-required-memory\\&#34;,\\n \\&#34;path\\&#34;: \\&#34;jsonpath::.spec.domain.resources.requests.memory\\&#34;,\\n \\&#34;rule\\&#34;: \\&#34;integer\\&#34;,\\n \\&#34;message\\&#34;: \\&#34;This VM requires more memory.\\&#34;,\\n \\&#34;min\\&#34;: 1610612736\\n }\\n]\\n&#34; }, &#34;labels&#34;: { &#34;app&#34;: &#34;rhel8-yywa22lijw8hl017&#34;, &#34;vm.kubevirt.io/template&#34;: &#34;rhel8-desktop-medium&#34;, &#34;vm.kubevirt.io/template.revision&#34;: &#34;1&#34;, &#34;vm.kubevirt.io/template.version&#34;: &#34;v0.19.5&#34; }, &#34;name&#34;: &#34;rhel8-yywa22lijw8hl017&#34; }, &#34;spec&#34;: { &#34;dataVolumeTemplates&#34;: [ { &#34;apiVersion&#34;: &#34;cdi.kubevirt.io/v1beta1&#34;, &#34;kind&#34;: &#34;DataVolume&#34;, &#34;metadata&#34;: { &#34;name&#34;: &#34;rhel8-yywa22lijw8hl017&#34; }, &#34;spec&#34;: { &#34;sourceRef&#34;: { &#34;kind&#34;: &#34;DataSource&#34;, &#34;name&#34;: &#34;rhel8&#34;, &#34;namespace&#34;: &#34;openshift-virtualization-os-images&#34; }, &#34;storage&#34;: { &#34;resources&#34;: { &#34;requests&#34;: { &#34;storage&#34;: &#34;30Gi&#34; } } } } } ], &#34;running&#34;: false, &#34;template&#34;: { &#34;metadata&#34;: { &#34;annotations&#34;: { &#34;vm.kubevirt.io/flavor&#34;: &#34;medium&#34;, &#34;vm.kubevirt.io/os&#34;: &#34;rhel8&#34;, &#34;vm.kubevirt.io/workload&#34;: &#34;desktop&#34; }, &#34;labels&#34;: { &#34;kubevirt.io/domain&#34;: &#34;rhel8-yywa22lijw8hl017&#34;, &#34;kubevirt.io/size&#34;: &#34;medium&#34; } }, &#34;spec&#34;: { &#34;domain&#34;: { &#34;cpu&#34;: { &#34;cores&#34;: 1, &#34;sockets&#34;: 1, &#34;threads&#34;: 1 }, &#34;devices&#34;: { &#34;disks&#34;: [ { &#34;disk&#34;: { &#34;bus&#34;: &#34;virtio&#34; }, &#34;name&#34;: &#34;rhel8-yywa22lijw8hl017&#34; }, { &#34;disk&#34;: { &#34;bus&#34;: &#34;virtio&#34; }, &#34;name&#34;: &#34;cloudinitdisk&#34; } ], &#34;inputs&#34;: [ { &#34;bus&#34;: &#34;virtio&#34;, &#34;name&#34;: &#34;tablet&#34;, &#34;type&#34;: &#34;tablet&#34; } ], &#34;interfaces&#34;: [ { &#34;masquerade&#34;: {}, &#34;name&#34;: &#34;default&#34; } ], &#34;networkInterfaceMultiqueue&#34;: true, &#34;rng&#34;: {} }, &#34;machine&#34;: { &#34;type&#34;: &#34;pc-q35-rhel8.4.0&#34; }, &#34;resources&#34;: { &#34;requests&#34;: { &#34;memory&#34;: &#34;4Gi&#34; } } }, &#34;evictionStrategy&#34;: &#34;LiveMigrate&#34;, &#34;networks&#34;: [ { &#34;name&#34;: &#34;default&#34;, &#34;pod&#34;: {} } ], &#34;terminationGracePeriodSeconds&#34;: 180, &#34;volumes&#34;: [ { &#34;dataVolume&#34;: { &#34;name&#34;: &#34;rhel8-yywa22lijw8hl017&#34; }, &#34;name&#34;: &#34;rhel8-yywa22lijw8hl017&#34; }, { &#34;cloudInitNoCloud&#34;: { &#34;userData&#34;: &#34;#cloud-config\\nuser: cloud-user\\npassword: nnpa-12td-e0r7\\nchpasswd: { expire: False }&#34; }, &#34;name&#34;: &#34;cloudinitdisk&#34; } ] } } } } ] } And to use the template to create a VM:
+oc process -n openshift rhel8-desktop-medium | oc apply -f - virtualmachine.kubevirt.io/rhel8-q63yuvxpjdvy18l7 created In just a few minutes, you will have a blank rhel8 VM running, which you can then login to (via console) and customize.
+Get the details of this template as a local YAML file: oc get template -n openshift rhel8-desktop-medium -o yaml &gt; my-template.yaml Once you have this local template, you can view the elements you want to customize, possibly using this as an example.
+HOWTO Define your own Ansible Controller Configuration The ansible_load_controller.sh is designed to be relatively easy to customize with a new controller configuration. Structurally, it is principally based on configure_controller.yml from the Red Hat Community of Practice controller_configuration collection. The order and specific list of roles invoked is taken from there.
+To customize it, the main thing would be to replace the different variables in the role tasks with the your own. The script includes the roles for variable types that this pattern does not manage in order to make that part straightforward. Feel free to add your own roles and playbooks (and add them to the controller configuration script).
+The reason this pattern ships with a script as it does instead of invoking the referenced playbook directly is that several of the configuration elements depend on each other, and there was not a super-convenient place to put things like the controller credentials as the playbook suggests.
+HOWTO substitute your own container application (instead of ignition) Adjust the query in the inventory_preplay.yml either by overriding the vars for the play, or forking the repo and replacing the vars with your own query terms. (That is, use your own label(s) and namespace to discover the services you want to connect to.
+Adjust or override the vars in the provision_kiosk.yml playbook to suitable values for your own container application. The roles it calls are fairly generic, so changing the vars is all you should need to do.
+Next Steps Help &amp; Feedback Report Bugs `,url:"https://validatedpatterns.io/patterns/ansible-edge-gitops/ideas-for-customization/",breadcrumb:"/patterns/ansible-edge-gitops/ideas-for-customization/"},"https://validatedpatterns.io/patterns/devsecops/ideas-for-customization/":{title:"Ideas for Customization",tags:[],content:`Ideas for Customization More desirable tools in the development pipeline One of the major goals of the Red Hat patterns development process is to create modular, customizable demos. Maybe there is a tool in the CI/CD pipeline that you&rsquo;d like to substitute for a preferred tool. E.g. using Clair in Quay to do image scanning instead of RH ACS. Or Quay Enterprise may be removed for another image repository.
+How to add a new tool to the pipeline In the region directory make a new directory that will house the Helm chart for your tool.
+Follow the guide on how to extend a pattern
+Deploying development and hub components to one cluster In some environments the organization may require a single cluster with different namespaces for development environments and hub environments. To achieve this you could combine the components in the development cluster group values-development.yaml file into the values-hub.yaml file.
+Things to consider. While OpenShift Pipelines needs to move to the values-hub.yaml file, the Quay bridge and ACS integration for pipeline scanning is not required. I.e. some of the plumbing needed to connect pipelines to various artifacts can be removed. Policies that are used by ACM move secrets to the development cluster would not be needed.
+Different production environments While this can be done with any of the patterns the Multicluster DevSecOps pattern is about building and deploying developed code. There maybe a variety of places where a deployment could land in production. Consider a smart city application. Various types of cluster groups could be used in production - a cluster group for traffic light applications, a cluster group for electric tram cars, a cluster group for smart road signs.
+values-traffic-lights.yaml
+values-tram-cars.yaml
+values-smart-signs.yaml
+GitOps and DevSecOps would be used to make sure that applications would be deployed on the correct clusters. Some of the &ldquo;clusters&rdquo; might be light single-node clusters. Some applications be be deployed to several cluster groups. E.g. the application to place information on a smart sign might also be deployed to the tram cars that also have smart signs in passenger compartments or the engineers compartment.
+`,url:"https://validatedpatterns.io/patterns/devsecops/ideas-for-customization/",breadcrumb:"/patterns/devsecops/ideas-for-customization/"},"https://validatedpatterns.io/patterns/industrial-edge/ideas-for-customization/":{title:"Ideas for Customization",tags:[],content:`Ideas for Customization Why change it? One of the major goals of the Red Hat patterns development process is to create modular, customizable demos. The Industrial Edge demonstration includes multiple, simulated, IoT devices publishing their temperature and vibration telemetry to our data center and ultimately persisting the data into an AWS S3 storage service bucket which we call the Data Lake. All of this is done using our Red Hat certified products running on OpenShift.
+This demo in particular can be customized in a number of ways that might be very interesting - and here are some starter ideas with some instructions on exactly what and where changes would need to be made in the pattern to accommodate those changes.
+HOWTO Forking the Industrial Edge repository to your github account Hopefully we are all familiar with GitHub. If you are not GitHub is a code hosting platform for version control and collaboration. It lets you and others work together on projects from anywhere. Our Industrial Edge GitOps repository is available in our Validated Patterns GitHub organization.
+To fork this repository, and deploy the Industrial Edge pattern, follow the steps found in our Getting Started section. This will allow you to follow the next few HOWTO guides in this section.
+Our sensors have been configured to send data relating to the vibration of the devices. To show the power of GitOps, and keeping state in a git repository, we can make a change to the config map of one of the sensors to detect and report data on temperature. This is done via a variable called SENSOR_TEMPERATURE_ENABLED that is initially set to false. Setting this variable to true will trigger the GitOps engine to synchronize the application, restart the machine sensor and apply the change.
+There are two environments in the Industrial Edge demonstration:
+The staging environment that lives in the manuela-tst-all namespace The production environment which lives in the stormshift namespaces As an operator you would first make changes to the staging first. Here are the steps to see how the GitOps engine does it&rsquo;s magic. These changes will be reflected in the staging environment Line Dashboard UI in the manuela-tst-all namespace.
+The config maps in question live in the charts/datacenter/manuela-tst/templates/machine-sensor directory There are two config maps that we can change: machine-sensor-1-configmap.yaml machine-sensor-2-configmap.yaml Change the following variable in machine-sensor-1-configmap.yaml SENSOR_TEMPERATURE_ENABLED: &ldquo;true&rdquo; Make sure you commit the changes to git git add machine-sensor-1-configmap.yaml git commit -m &ldquo;Changed SENSOR_TEMPERATURE_ENABLED to true&rdquo; git push Now you can go to the Line Dashboard application and see how the UI shows the temperature for that device. You can find the route link by: Change the Project context to manuela-tst-all Navigate to Networking-&gt;Routes Press on the Location link to see navigate to the UI. HOWTO Applying the pattern to a new use case There are a lot of IoT devices that we could add to this pattern. In today&rsquo;s world we have IoT devices that perform different functions and these devices are connected to a network where they have the ability of sending telemetry data to other devices or a central data center. In this particular use case we address an Industrial sector but what about applying this use case to other sectors such as Automotive or Delivery service companies?
+If we take the Deliver Service use case, and apply it to this pattern, we would have to take into account the following aspects:
+The main components in the pattern architecture can be used as is. The broker and kafka components are the vehicles for the streaming data coming from the devices. The IoT sensor software would have to be developed. The IoT devices will now be mobile so that presents a few challenges tracking the devices in part due to spotty connectivity to send the data stream. The number of IoT devices to be tracked will increase depending on the fleet of delivery trucks out in the field. Scalability will be an important aspect for the pattern to be able to handle. A new AI/ML model would have to be developed to &ldquo;learn&rdquo; through the analysis of the data stream from the IoT devices. The idea is that this pattern can be used for other use cases keeping the main components in place. The components that would be new to the pattern are: IoT device code, AI/ML models, and specific kafka/broker topics to keep track of.
+Next Steps 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 &amp; Feedback{: .btn .fs-5 .mb-4 .mb-md-0 .mr-2 } Report Bugs{: .btn .btn-red .fs-5 .mb-4 .mb-md-0 .mr-2 }
+`,url:"https://validatedpatterns.io/patterns/industrial-edge/ideas-for-customization/",breadcrumb:"/patterns/industrial-edge/ideas-for-customization/"},"https://validatedpatterns.io/patterns/multicloud-gitops-portworx/ideas-for-customization/":{title:"Ideas for Customization",tags:[],content:`Ideas for customization Why change it? One of the major goals of the Red Hat patterns development process is to create modular, customizable demos. The Multicloud Gitops is just an example of a pattern managing multiple clusters in a gitops fashion. It contains a very simple &lsquo;config-demo&rsquo; application which prints out a secret that was injected into the vault via an out-of-band mechanism.
+It could be an interesting exercise to customize this demo in different ways.
+Split the config-demo across hub and regional clusters Currently hub and regional clusters are reusing the exact same helm chart found at charts/all/config-demo. The first customization step could be to split the demo app in two separate charts: one in charts/hub/config-demo and one in charts/region/config-demo. Once charts/all/config-demo has been copied to charts/hub/config-demo and charts/region/config-demo, we need to include them in the respective values-hub.yaml and values-region-one.yaml, respectively.
+Once this is done we can start customizing the two apps and make them output a different web page entirely depending if the pod is running on the hub or on the cluster.
+Rest API addition Another idea, after splitting the charts, could be to implement a small Rest API server on the hub. This API could serve read-only values out to anyone and could provide some update write-APIs only if the client provides a secret (for example via the X-API-KEY mechanism). The config-demo application could be tweaked to talk to the hub and use a vault-injected secret as the X-API-KEY. So the hub would possess the key via the External-Secrets generated K8s secret and the regional app would possess that same secret via the ACM policy pushing out secrets via the {{hub fromSecret}} mechanism.
+In the end the possibilities to tweak this pattern are endless. Do let us know if you have an awesome idea that you&rsquo;d like to add
+Contribute to this pattern: Help &amp; Feedback{: .btn .fs-5 .mb-4 .mb-md-0 .mr-2 } Report Bugs{: .btn .btn-red .fs-5 .mb-4 .mb-md-0 .mr-2 }
+`,url:"https://validatedpatterns.io/patterns/multicloud-gitops-portworx/ideas-for-customization/",breadcrumb:"/patterns/multicloud-gitops-portworx/ideas-for-customization/"},"https://validatedpatterns.io/patterns/retail/ideas-for-customization/":{title:"Ideas for Customization",tags:[],content:"Ideas for Customization ",url:"https://validatedpatterns.io/patterns/retail/ideas-for-customization/",breadcrumb:"/patterns/retail/ideas-for-customization/"},"https://validatedpatterns.io/learn/workflow/":{title:"Workflow",tags:[],content:`Workflow These patterns are designed to be composed of multiple components, and for those components to be used in gitops workflows by consumers and contributors. To use the first pattern as an example, we maintain the Industrial Edge pattern, which uses a repo with pattern-specific logic and configuration as well as a common repo which has elements common to multiple patterns. The common repository is included in each pattern repository as a subtree.
+Consuming a pattern Fork the pattern repository on GitHub to your workspace (GitHub user or organization). It is necessary to fork because your fork will be updated as part of the GitOps and DevOps processes, and the main branch (by default) will be used in the automated workflows.
+Clone the forked copy
+git clone git@github.com:&lt;your-workspace&gt;/industrial-edge.git
+Create a local copy of the Helm values file that can safely include credentials
+DO NOT COMMIT THIS FILE You do not want to push personal credentials to GitHub.
+$ cp values-secret.yaml.template ~/values-secret.yaml $ vi ~/values-secret.yaml Customize the deployment for your cluster
+$ vi values-global.yaml $ git commit values-global.yaml $ git push Contributing For contributions, we recommend adding the upstream repository as an additional remote, and making changes on a branch other than main. Changes on this branch can then be merged to the main branch (to be reflected in the GitOps workflows) and will be easier to make upstream, if you wish. Contributions from your forked main branch will contain, by design:
+Customizations to values-global.yaml and other files that are particular to your installation
+Commits made by Tekton and other automated processes that will be particular to your installation
+To isolate changes for upstreaming (hcp is &#34;Validated Patterns&#34;, you can use a different remote and/or branch name if you want):
+$ git remote add hcp https://github.com/validatedpatterns/industrial-edge $ git fetch --all $ git branch -b hcp-main -t hcp/main &lt;make changes on the hcp-main branch&gt; $ git push origin hcp-main To update branch hcp-main with upstream changes:
+$ git checkout hcp-main $ git pull --rebase To reflect these changes in your forked repository (such as if you would like to submit a PR later):
+$ git push origin hcp-main If you want to integrate upstream pattern changes into your local GitOps process:
+$ git checkout main $ git merge hcp-main $ git push origin main Using this workflow, the hcp-main branch will:
+Be isolated from any changes that are being made by your local GitOps processes
+Be merge-able (or cherry-pick-able) into your local main branch to be used by your local GitOps processes (this is especially useful for tracking when any submodules, like common, update)
+Be a good basis for submitting Pull Requests to be integrated upstream, since it will not contain your local configuration differences or your local GitOps commits
+Changing subtrees Our patterns use the git subtree feature as a mechanism to promote modularity, so that multiple patterns can use the same common basis. Over time we will move more functionality into common, to isolate the components that are particular to each pattern, and standard usage conventions emerge. This will make the tools in common more powerful and featureful, and make it easier to develop new patterns. Normally, we will maintain the common subtree in the normal course of updates, and pulling changes from upstream will include any changes from common.
+You only need to change subtrees if you want to test changes in the common/ area of the pattern repositories, or if you wish to contribute to the common/ repository itself in conjunction with one of the patterns. Using the pattern by itself does not require changing subtrees.
+For the common cases (use and consumption of the pattern), users do not need to be aware that the pattern uses a subtree at all.
+$ git clone https://github.com/&lt;your-workspace&gt;/industrial-edge If you want to change and track your own version of common, you should fork and clone our common repository separately:
+$ git clone https://github.com/&lt;your-workspace&gt;/common Now, you can make changes in your fork’s main branch, or else make a new branch and make changes there.
+If you want to track these changes in your fork of the pattern repository (industrial-edge in this case), you will need to swap out the subtree in industrial-edge for the version of common you forked. We have provided a script to make this a bit easier:
+$ common/scripts/make_common_subtree.sh &lt;subtree_repo&gt; &lt;subtree_branch&gt; &lt;subtree_remote_name&gt; This script will set up a new remote in your local working directory with the repository you specify. It will replace the common directory with a new common from the fork and branch you specify, and commit it. The script will not push the result.
+For example:
+$ common/scripts/make_common_subtree.sh https://github.com/mhjacks/common.git wip-main common-subtree This will replace common in the current repository with the wip-main branch from the common in mhjacks’s common repository, and call the remote common-subtree.
+From that point, changes from mhjacks’s wip-main branch on mhjacks’s fork of common can be pulled in this way:
+$ git subtree pull --prefix common common-subtree wip-main When run without arguments, the script will run as if it had been given the following arguments:
+$ common/scripts/make_common_subtree.sh https://github.com/validatedpatterns/common.git main common-subtree Which are the defaults the repository is normally configured with.
+Subtree vs. Submodule It has always been important to us to be have a substrate for patterns that is as easy as possible to share amongst multiple patterns. While it is possible to share changes between multiple unrelated git repositories, it is an almost entirely manual process, prone to error. We feel it is important to be able to provide a &#34;pull&#34; experience (i.e. one git &#34;pull&#34; type action) to update the shared components of a pattern. Two strategies exist for repository sharing in this way: submodule and subtree. We started with submodules but have since moved to subtree.
+Atlassian has some good documentation on what subtree is here and here. In short, a subtree integrates another repository’s history into a parent repository, which allows for most of the benefits of a submodule workflow, without most of the caveats.
+Earlier versions of this document described the usage of patterns with submodules instead of subtrees. In the earliest stages of pattern development, we used submodules because the developers of the project were familiar with submodules and had used them previously, but we had not used subtrees. User feedback, as well as some of the unavoidable complexities of submodules, convinced us to try subtrees and we believe we will stick with that strategy. Some of the unavoidable complexities of submodules include:
+Having to remember to checkout repositories with --recurse-submdules, or else doing git submodule init &amp;&amp; git submodule sync. Experienced developers asked in several of our support channels early on why common was empty.
+Hoping that other tools that are interacting with the repository are compatible with the submodule approach. (To be fair, tools like ArgoCD and Tekton Pipelines did this very well; their support of submodules was one of the key reasons we started with submodules)
+When changing branches on a submoduled repository, if the branch you were changing to was pointed to a different revision of the submoduled repository, the repository would show out of sync. While this behavior is correct, it can be surprising and difficult to navigate.
+In disconnected environments, submodules require mirroring more repositories.
+Developing with a fork of the submoduled repository means maintaining two forked repositories and multiple branches in both.
+Subtrees have some pitfalls as well. In the subtree strategy, it is easier to diverge from the upstream version of the subtree repository, and in fact with a typical git clone, the user may not be aware that a subtree is in use at all. This can be considered a feature, but could become problematic if the user/consumer later wants to update to a newer version of the subtree but local changes might conflict. Additionally, since subtrees are not as well understood generally, there can be some surprising effects. In practice, we have run into the following:
+Cherry picking from a subtree commit into the parent puts the change in the parent location, not the subtree
+Contributing to Patterns using Common Subtrees Once you have forked common and changed your subtree for testing, changes from your fork can then be proposed to [https://github.com/validatedpatterns/common.git] and can then be integrated into other patterns. A change to upstream common for a particular upstream pattern would have to be done in two stages:
+PR the change into upstream’s common
+PR the updated common into the pattern repository
+`,url:"https://validatedpatterns.io/learn/workflow/",breadcrumb:"/learn/workflow/"},"https://validatedpatterns.io/learn/secrets-management-in-the-validated-patterns-framework/":{title:"Secrets management in the Validated Patterns framework",tags:[],content:`Overview of secrets management Secrets management is a critical aspect of software development, especially when dealing with sensitive information such as passwords, API keys, and tokens. In the context of GitOps, where the state of an application is stored in a Git repository, managing secrets requires careful handling to avoid exposing sensitive information. Managing secrets in values files involves securely handling this sensitive information within configuration files, ensuring that these secrets are safely stored and managed, thereby reducing the risk of exposure or unauthorized access.
+Recommended Practices
+Avoid committing secrets to Git repositories: Never store secrets directly in Git repositories, including private ones, as they can be accidentally exposed or accessed by unauthorized users. If secrets are committed, they should be considered compromised and rotated immediately.
+Use secret references: Instead of storing actual secret values in configuration files, store references to those secrets. This method is supported by major secret management solutions like HashiCorp Vault, AWS Secrets Manager, and Azure Key Vault. Applications can fetch the secrets securely at runtime using these references.
+Encrypt secrets at rest: Always encrypt secrets wherever they are stored. This includes encrypting files on local machines, using encrypted storage solutions, and leveraging built-in encryption mechanisms provided by secret management tools. Ansible, for example, supports encryption of files at rest with tools like ansible-vault.
+Use external secret management tools: Use external tools like the External Secrets Operator (ESO) to manage secrets outside of the application’s core configuration. This reduces the risk of accidental exposure and ensures a more secure secret management process.
+Basic secrets configuration in a ClusterGroup The secrets required for a pattern are not directly represented in the ClusterGroup configuration. Instead, the values-secret.yaml.template file located in the root of validated patterns specifies the necessary secrets, detailing the required data types and keys for each pattern.
+In this template file, the secrets key contains an array of secrets. Each secret includes an array of fields, where each field has a name and value that describe the structure of the secret as used by the pattern.
+The pattern framework uses the configured SecretStore backend to inject the secrets into the configured backend. Additionally, values can be retrieved in other ways than specifying a string value. This is convenient when the secret material, such as SSH private and/or public keys, already exists as a file elsewhere on the machine from which the pattern is being installed. The framework also supports encoding the field using base64, which is required for binary data files, such as Red Hat Satellite-style manifests.
+Secret file processing in the framework The secrets loader in the framework, triggered by make load-secrets (also run as part of make install), searches for files in the following order and uses the first one found:
+~/.config/hybrid-cloud-patterns/values-secret-{{ pattern_name }}.yaml
+~/.config/validated-patterns/values-secret-{{ pattern_name }}.yaml
+~/values-secret-{{ pattern_name }}.yaml
+~/values-secret.yaml
+{{ pattern_dir }}/values-secret.yaml.template
+Here, “pattern_name” refers to the pattern name (for example, “ansible-edge-gitops”, “industrial-edge”), and “pattern_dir” is the root directory of the locally checked-out pattern. This scheme allows for separate secret files for different patterns or a single file for all patterns. If the secrets file is encrypted, the load-secrets process prompts for the password. When entered, the process will continue and the secrets will be loaded.
+Values secret file structure The values secret file comprises top-level keys and sub-parameters, facilitating the management of secrets within the backend.
+Top-Level keys:
+version: (Optional): Must be “2.0” if specified. Defaults to a deprecated 1.0 schema if not specified.
+backingStore: (Optional): Defaults to the backingStore configured in values-global. If specified, it must match values-global. It is best not to include it.
+vaultPolicies: (Optional): Allows injecting vault policies for automatic password generation; effective only when the secrets backend is vault. It’s a dictionary, allowing multiple policies.
+secrets: The actual secrets to inject into the backend, with each secret having various sub-fields as described below.
+Sub-parameters name: Indicates the name of the secret within the backend.
+fields: Defines the fields within the secret object. Each field has a name and a value. In the template file, the value is used as a placeholder to define the use of the field. This is used by the framework in error messages related to the field.
+targetNamespaces: (Optional, effective with “Kubernetes” or “none” backends): Secret objects are created in all specified namespaces. Multiple namespaces are allowed as the same secret material may need to be injected into multiple secret objects in different namespaces.
+labels: (Optional, effective with “Kubernetes” and “none” backends): Kubernetes labels to add to secret objects created through the framework.
+annotations: (Optional, effective with “Kubernetes” and “none” backends): Kubernetes annotations to add to secret objects created through the framework.
+type: (Optional, effective with “Kubernetes” and “none” backends): Kubernetes “type” of secret object. Defaults to “Opaque” if unspecified.
+vaultPrefixes: (Optional, only effective with vault backend): Keys in vault belong to prefixes, allowing creation of the same key with multiple prefixes.
+Fields sub-parameters name: Each field in a secret must have a unique, descriptive name (for example, username, password, manifest_content).
+value: (Optional, technically): Actual secret material. Can be provided via equivalent convenience functions. Value designates content directly, but the framework can also use file contents or parse an ini-file for data. In the template yaml, we always specify value with a description of the name/value pair.
+path: (Optional): Local file to use as secret content. Framework understands ~ (user home directory) expansion under Linux, Mac, and WSL for convenience.
+ini_file: (Optional) : Ini-file to retrieve secret material from. Must also include ini_key.
+ini_key: (Optional): Ini_key within the ini file to retrieve secret material from.
+ini_section: (Optional): Ini_section within an ini_file to retrieve the key from. Needed only for ini files with multiple sections.
+base64: (Optional): Boolean value (true/false, default is false) to base64-encode secret material before sending it to the secrets backend. This is independent of the other options, so you can specify plaintext file path and not specify base64 for encoding, or specify a binary file along with base64: true for encoding.
+onMissingValue: (Optional): (error/prompt/generate) Specifies behavior when the values secret file does not contain a value for the field. By default it throws an error. The “prompt” option asks user to input a secret on the keyboard. The “generate” option uses vault’s secret generation feature to create a suitable secret.
+override: (Optional, only effective with vault backend): When onMissingValue is set to “generate” and a secret has already been generated, ensures a new one is generated each time the secrets loader is run.
+vaultPolicy: (Optional; only effective with vault backend): Defines the vault policy (which defines allowable character types and overall length) to use when generating a secret.
+Examples: Here are examples demonstrating the template file from AnsibleEdge GitOps and reasonable ways to provide the secret values using the convenience mechanisms provided by the framework. Alternatively, values can be directly filled in using the value field with the literal contents of each secret.
+Template File:
+version: &#34;2.0&#34; secrets: - name: aws-creds fields: - name: aws_access_key_id value: &#34;An aws access key that can provision VMs and manage IAM (if using portworx)&#34; - name: aws_secret_access_key value: &#34;An aws access secret key that can provision VMs and manage IAM (if using portworx)&#34; - name: kiosk-ssh fields: - name: username value: &#39;Username of user to attach privatekey and publickey to - cloud-user is a typical value&#39; - name: privatekey value: &#39;Private ssh key of the user who will be able to elevate to root to provision kiosks&#39; - name: publickey value: &#39;Public ssh key of the user who will be able to elevate to root to provision kiosks&#39; - name: rhsm fields: - name: username value: &#39;username of user to register RHEL VMs&#39; - name: password value: &#39;password of rhsm user in plaintext&#39; - name: kiosk-extra fields: # Default: &#39;--privileged -e GATEWAY_ADMIN_PASSWORD=redhat&#39; - name: container_extra_params value: &#34;Optional extra params to pass to kiosk ignition container, including admin password&#34; - name: cloud-init fields: - name: userData value: |- #cloud-config user: &#39;username of user for console, probably cloud-user&#39; password: &#39;a suitable password to use on the console&#39; chpasswd: { expire: False } - name: aap-manifest fields: - name: b64content path: &#39;full pathname of file containing Satellite Manifest for entitling Ansible Automation Platform&#39; base64: true Providing values in a “real” values-secret.yaml:
+version: &#34;2.0&#34; secrets: - name: aws-creds fields: - name: aws_access_key_id ini_file: ~/.aws/credentials ini_key: aws_access_key_id - name: aws_secret_access_key ini_file: ~/.aws/credentials ini_key: aws_secret_access_key - name: kiosk-ssh fields: - name: username value: &#39;cloud-user&#39; - name: privatekey path: ~/.ssh/id_cloud_user - name: publickey Path: ~/.ssh/id_cloud_user.pub - name: rhsm fields: - name: username value: &#39;rhsm-user&#39; - name: password value: &#39;rhsm-password&#39; - name: kiosk-extra fields: # Default: &#39;--privileged -e GATEWAY_ADMIN_PASSWORD=redhat&#39; - name: container_extra_params value: &#34;--privileged -e GATEWAY_ADMIN_PASSWORD=B3tt3RP8ssw@rd&#34; - name: cloud-init fields: - name: userData value: |- #cloud-config user: &#39;cloud-user&#39; password: &#39;aaaa-bbbbb-ccccc-ddddd&#39; chpasswd: { expire: False } - name: aap-manifest fields: - name: b64content path: &#39;~/manifest_Pattern_20240605T170000Z.zip&#39; base64: true Secret store configuration in a ClusterGroup The secretStore parameter defines the configuration for connecting to the secret management backend. This parameter allows the ClusterGroup to interact with the chosen secret storage solution. It is normally configured in the values-global.yaml configuration file. The framework provides tools for modifying the secret store configuration.
+Many historical patterns have a separate secretStore key. However, the new recommendation is to use the global.secretStore key instead. In general using the tools provided to configure a pattern secrets backend is recommended, as there are implications for both the hashicorp-vault and golang-external-secrets charts, as well as the clustergroup namespace lists.
+Sub-parameters backend: Specifies the secret store backend, currently supporting “vault”, “Kubernetes”, or “none”. The default is “vault.”
+kind: This may be “SecretStore” or “ClusterSecretStore”. In most cases, patterns opt for ClusterSecretStore as it enables access from multiple namespaces. “ClusterSecretStore” is the default.
+Examples: In values-global.yaml:
+global: secretStore: backend: kubernetes Secrets backends in the Validated Patterns framework The validated patterns framework currently supports three secrets storage schemes:
+secrets-backend-vault: This is the default scheme where the community edition of HashiCorp Vault and the External Secrets Operator are installed. Secrets are stored in vault and then projected into the pattern via External Secrets objects. This approach ensures versionable secrets without exposing them in a Git repository.
+secrets-backend-Kubernetes: The Kubernetes secrets backend also uses the community External Secrets Operator, but rather than injecting secrets into Vault (which is not installed when this backend is selected), secrets are injected into a separate Kubernetes namespace. ESO still brokers the projection of these secrets into the pattern.
+secrets-backend-none: In this scheme, secret objects are directly injected into the pattern, based on the values-secret configuration. Neither Vault nor the External Secrets Operator are installed. This method is provided for users who require full Red Hat Supportability for their pattern installations.
+Switching between secrets backends The framework provides Makefile-based mechanisms for changing secrets storage schemes. It is recommended to decide on a secrets storage mechanism before installing the pattern. To configure your pattern with a different secrets storage scheme, run the appropriate make target. This is only necessary if you want to switch from the vault scheme, as all patterns come configured with the vault backend by default. The Makefile targets modifies the values file in your pattern repository, which you must then commit and push to take effect. The changes made by the Makefile targets will be displayed in &#34;diff&#34; format.
+Example: Setting backend to Kubernetes for the Ansible Edge GitOps pattern:
+% make secrets-backend-kubernetes make -f common/Makefile secrets-backend-kubernetes make[1]: Entering directory &#39;/home/martjack/gitwork/edge/ansible-edge-gitops&#39; common/scripts/set-secret-backend.sh kubernetes common/scripts/manage-secret-namespace.sh validated-patterns-secrets present Namespace validated-patterns-secrets not found, adding common/scripts/manage-secret-app.sh vault absent Removing namespace vault Removing application wth chart location common/hashicorp-vault common/scripts/manage-secret-app.sh golang-external-secrets present diff --git a/values-global.yaml b/values-global.yaml index e594a84..adbd0fa 100644 --- a/values-global.yaml +++ b/values-global.yaml @@ -1,15 +1,14 @@ --- global: pattern: ansible-edge-gitops - options: useCSV: false syncPolicy: Automatic installPlanApproval: Automatic - hub: provider: aws storageClassName: gp2 - + secretStore: + backend: kubernetes main: clusterGroupName: hub diff --git a/values-hub.yaml b/values-hub.yaml index ccf662d..463f24b 100644 --- a/values-hub.yaml +++ b/values-hub.yaml @@ -2,31 +2,25 @@ clusterGroup: name: hub isHubCluster: true - namespaces: - - vault - golang-external-secrets - ansible-automation-platform - openshift-cnv - openshift-storage - edge-gitops-vms - + - validated-patterns-secrets subscriptions: aap-operator: name: ansible-automation-platform-operator namespace: ansible-automation-platform - openshift-virtualization: name: kubevirt-hyperconverged namespace: openshift-cnv - openshift-data-foundation: name: odf-operator namespace: openshift-storage - projects: - hub - imperative: jobs: - name: deploy-kubevirt-worker @@ -52,36 +46,25 @@ clusterGroup: - get - list - watch - applications: aap: name: ansible-automation-platform project: hub path: charts/hub/ansible-automation-platform - aap-config: name: aap-config project: hub path: charts/hub/aap-config - - vault: - name: vault - namespace: vault - project: hub - path: common/hashicorp-vault - golang-external-secrets: name: golang-external-secrets namespace: golang-external-secrets project: hub path: common/golang-external-secrets - openshit-cnv: name: openshift-cnv namespace: openshift-cnv project: hub path: charts/hub/cnv - odf: name: odf namespace: openshift-storage @@ -89,12 +72,10 @@ clusterGroup: path: charts/hub/openshift-data-foundations extraValueFiles: - &#39;/overrides/values-odf-{{ $.Values.global.clusterPlatform }}-{{ $.Values.global.clusterVersion }}.yaml&#39; - edge-gitops-vms: name: edge-gitops-vms namespace: edge-gitops-vms project: hub path: charts/hub/edge-gitops-vms - # Only the hub cluster here - managed entities are edge nodes managedClusterGroups: [] Secrets backend set to kubernetes, please review changes, commit, and push to activate in the pattern make[1]: Leaving directory &#39;/home/martjack/gitwork/edge/ansible-edge-gitops&#39; Setting backend to none in Ansible Edge GitOps:
+% make secrets-backend-none make -f common/Makefile secrets-backend-none make[1]: Entering directory &#39;/home/martjack/gitwork/edge/ansible-edge-gitops&#39; common/scripts/set-secret-backend.sh none common/scripts/manage-secret-app.sh vault absent Removing namespace vault Removing application wth chart location common/hashicorp-vault common/scripts/manage-secret-app.sh golang-external-secrets absent Removing namespace golang-external-secrets Removing application wth chart location common/golang-external-secrets common/scripts/manage-secret-namespace.sh validated-patterns-secrets absent Removing namespace validated-patterns-secrets diff --git a/values-global.yaml b/values-global.yaml index e594a84..62d43c8 100644 --- a/values-global.yaml +++ b/values-global.yaml @@ -1,15 +1,14 @@ --- global: pattern: ansible-edge-gitops - options: useCSV: false syncPolicy: Automatic installPlanApproval: Automatic - hub: provider: aws storageClassName: gp2 - + secretStore: + backend: none main: clusterGroupName: hub diff --git a/values-hub.yaml b/values-hub.yaml index ccf662d..b9e168e 100644 --- a/values-hub.yaml +++ b/values-hub.yaml @@ -2,31 +2,23 @@ clusterGroup: name: hub isHubCluster: true - namespaces: - - vault - - golang-external-secrets - ansible-automation-platform - openshift-cnv - openshift-storage - edge-gitops-vms - subscriptions: aap-operator: name: ansible-automation-platform-operator namespace: ansible-automation-platform - openshift-virtualization: name: kubevirt-hyperconverged namespace: openshift-cnv - openshift-data-foundation: name: odf-operator namespace: openshift-storage - projects: - hub - imperative: jobs: - name: deploy-kubevirt-worker @@ -52,36 +44,20 @@ clusterGroup: - get - list - watch - applications: aap: name: ansible-automation-platform project: hub path: charts/hub/ansible-automation-platform - aap-config: name: aap-config project: hub path: charts/hub/aap-config - - vault: - name: vault - namespace: vault - project: hub - path: common/hashicorp-vault - - golang-external-secrets: - name: golang-external-secrets - namespace: golang-external-secrets - project: hub - path: common/golang-external-secrets - openshit-cnv: name: openshift-cnv namespace: openshift-cnv project: hub path: charts/hub/cnv - odf: name: odf namespace: openshift-storage @@ -89,12 +65,10 @@ clusterGroup: path: charts/hub/openshift-data-foundations extraValueFiles: - &#39;/overrides/values-odf-{{ $.Values.global.clusterPlatform }}-{{ $.Values.global.clusterVersion }}.yaml&#39; - edge-gitops-vms: name: edge-gitops-vms namespace: edge-gitops-vms project: hub path: charts/hub/edge-gitops-vms - # Only the hub cluster here - managed entities are edge nodes managedClusterGroups: [] Secrets backend set to none, please review changes, commit, and push to activate in the pattern make[1]: Leaving directory &#39;/home/martjack/gitwork/edge/ansible-edge-gitops&#39; Letsencrypt secrets configuration in a ClusterGroup The letsencrypt parameter configures the use of Letsencrypt for obtaining and managing SSL certificates. This ensures OpenShift clusters have valid SSL certificates, replacing the default self-signed certificates. In regular production environments, clusters are expected to be deployed using an organization’s own certificates, instead of default self-signed ones. Letsencrypt, a popular service providing trusted certificates for web services, eliminates browser security warnings and errors caused by self-signed certificates.
+The certificates requested by letsencrypt come from the global.localClusterDomain setting.
+Support Level
+AWS Only: Letsencrypt integration is currently supported only on AWS environments within the validated patterns framework.
+Example: Enabling letsencrypt support
+To enable Let’s Encrypt support, add the following entries to values-AWS.yaml in the pattern root directory. Be sure to adjust the region: and email: settings as needed:
+letsencrypt: region: eu-central-1 server: https://acme-v02.api.letsencrypt.org/directory email: foo@bar.it clusterGroup: applications: letsencrypt: name: letsencrypt namespace: letsencrypt project: default path: common/letsencrypt Sub-parameters region: The AWS region where the cluster is running.
+server: The letsencrypt server endpoint for authentication.
+email: The e-mail address to use as a DNS contact.
+`,url:"https://validatedpatterns.io/learn/secrets-management-in-the-validated-patterns-framework/",breadcrumb:"/learn/secrets-management-in-the-validated-patterns-framework/"},"https://validatedpatterns.io/learn/vault/":{title:"HashiCorp Vault",tags:[],content:` Deploying HashiCorp Vault in a validated pattern Prerequisites You have deployed/installed a validated pattern using the instructions provided for that pattern. This should include setting having logged into the cluster using oc login or setting you KUBECONFIG environment variable and running a ./pattern.sh make install.
+Setting up HashiCorp Vault Any validated pattern that uses HashiCorp Vault already has deployed Vault as part of the ./pattern.sh make install. To verify that Vault is installed you can first see that the vault project exists and then select the Workloads/Pods:
+The setup for HashiCorp Vault happens automatically as part of the ./pattern.sh make install command. A cronjob will run every five minutes inside the imperative namespace and unseal, initialize and configure the vault. The vault’s unseal keys and root token will be stored inside a secret called vaultkeys in the imperative namespace.
+It is recommended that you copy the contents of that secret offline, store it securely, and then delete it. It will not be recreated after the vault is unsealed. You can back it up to a file with the following command: oc get -n imperative secrets/vaultkeys -o yaml &gt; &lt;path-to-secret-storage&gt;/vault-unseal-keys.yaml. Then you may delete it from the cluster by running oc delete -n imperative secret/vaultkeys. The unseal keys will be needed to unseal the vault again should its pod be restarted. You can restore the vaultkeys with oc apply -f &lt;path-to-secret-storage&gt;/vault-unseal-keys.yaml and then wait for the CronJob called unseal-vault to run (the default is every five minutes). Remember to delete the vaultkeys secret again once the vault is unsealed
+An example output from running the oc extract -n imperative secret/vaultkeys --to=- --keys=vault_data_json 2&gt;/dev/null command:
+{ &#34;recovery_keys_b64&#34;: [], &#34;recovery_keys_hex&#34;: [], &#34;recovery_keys_shares&#34;: 0, &#34;recovery_keys_threshold&#34;: 0, &#34;root_token&#34;: &#34;hvs.VNFq7yPuZljq2VDJTkgAMs2Z&#34;, &#34;unseal_keys_b64&#34;: [ &#34;+JJjKgZyEB1rbKlXs1aTuC+PBivukIlnpoe7bH4qc7TL&#34;, &#34;X2ib6LNZw+kOQH1WYR9t3RE2SgB5WbEf2FfD40OybNXf&#34;, &#34;A4DIhv9atLIQsqqyDAYkmfEJPYhFVuKGSGYwV7WCtGcL&#34;, &#34;ZWkQ7+qtgmClKdlNKWcdpvyxArm07P9eArHZB4/CMZWn&#34;, &#34;HXakF073+Kk7oOpAFbGlKIWYApzUhC/F1LDfowF/M1LK&#34; ], &#34;unseal_keys_hex&#34;: [ &#34;f892632a0672101d6b6ca957b35693b82f8f062bee908967a687bb6c7e2a73b4cb&#34;, &#34;5f689be8b359c3e90e407d56611f6ddd11364a007959b11fd857c3e343b26cd5df&#34;, &#34;0380c886ff5ab4b210b2aab20c062499f1093d884556e28648663057b582b4670b&#34;, &#34;656910efeaad8260a529d94d29671da6fcb102b9b4ecff5e02b1d9078fc23195a7&#34;, &#34;1d76a4174ef7f8a93ba0ea4015b1a5288598029cd4842fc5d4b0dfa3017f3352ca&#34; ], &#34;unseal_shares&#34;: 5, &#34;unseal_threshold&#34;: 3 } The vault’s root token is needed to log into the vault’s UI and the unseal keys are needed whenever the vault pods are restarted. In the OpenShift console click on the nine box at the top and click on the vault line:
+Copy the root_token field which in the example above has the value hvs.VNFq7yPuZljq2VDJTkgAMs2Z and paste it in the sign-in page:
+After signing in you will see the secrets that have been created.
+Unseal If you don’t see the sign in page but instead see an unseal page, something may have happened the cluster and you need to unseal it again. Make sure that the imperative/vaultkeys secret exists and wait for the CronJob called unseal-vault inside the imperative namespace to run. Alternatively you could unseal the vault manually by running vault operator commands inside the vault-0 pod. See these instructions for additional information.
+What’s next? Check with the validated pattern instructions to see if there are further steps you need to perform. Sometimes this might be deploying a pattern on an edge cluster and checking to see if the correct Vault handshaking and updating occurs.
+`,url:"https://validatedpatterns.io/learn/vault/",breadcrumb:"/learn/vault/"},"https://validatedpatterns.io/learn/implementation/":{title:"Implementation requirements",tags:[],content:` Technical requirements Consider these requirements specific to the implementation of all Validated Patterns and their tiers.
+The requirements are categorized as follows:
+Must These are nonnegotiable, core requirements that must be implemented.
+Should These are important but not critical; their implementation enhances the pattern.
+Can These are optional or desirable features, but their absence does not hinder the implementation of a pattern.
+Must Patterns must include one or more Git repositories in a publicly accessible location, containing configuration elements that can be consumed by the Red Hat OpenShift GitOps Operator without supplying custom Argo CD images.
+Patterns must be useful without all content stored in private Git repositories.
+Patterns must include a list of names and versions of all the products and projects that the pattern consumes.
+Patterns must be useful without any sample applications that are private or that lack public sources.
+Patterns must not degrade due to lack of updates or opaque incompatibilities in closed source applications.
+Patterns must not store sensitive data elements including, but not limited to, passwords in Git repositories.
+Patterns must be possible to deploy on any installer-provisioned infrastructure OpenShift cluster (BYO).
+Validated Patterns distinguish between the provisioning and configuration requirements of the initial cluster (Patterns) and of clusters or machines that are managed by the initial cluster (Managed clusters).
+Patterns must use a standardized clustergroup Helm chart as the initial Red Hat OpenShift GitOps application that describes all namespaces, subscriptions, and any other GitOps applications which contain the configuration elements that make up the solution.
+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.
+Imperative elements must be implemented as idempotent code stored in Git repository.
+Should Patterns should include sample applications to demonstrate the business problems addressed by the pattern.
+Patterns should try to indicate which parts are foundational as opposed to being for demonstration purposes.
+Patterns should use the Validated Patterns Operator to deploy patterns. However, anything that creates the OpenShift GitOps subscription and initial clustergroup application could be acceptable.
+Patterns should embody the Open Hybrid Cloud model unless there is a compelling reason to limit the availability of functionality to a specific platform or topology.
+Patterns should use industry standards and Red Hat products for all required tooling.
+Patterns require 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.
+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.
+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.
+Patterns should be decomposed into modules that perform a specific function, so that they can be reused in other patterns.
+For example, Bucket Notification is a capability in the Medical Diagnosis pattern that could be used for other solutions.
+Patterns should use Red Hat Ansible Automation Platform to drive the declarative provisioning and management of managed hosts, for example, Red Hat Enterprise Linux (RHEL). See also Imperative elements.
+Patterns should use Red Hat Advanced Cluster Management (RHACM) to manage policy and compliance on any managed clusters.
+Patterns should use RHACM and a standardized RHACM chart to deploy and configure OpenShift GitOps to managed clusters.
+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.
+Managed clusters should use the pull deployment model for obtaining their configuration.
+Imperative elements should be implemented as Ansible playbooks.
+Imperative elements should be driven declaratively implying that the playbooks should be triggered by Jobs or CronJobs stored in Git and delivered by OpenShift GitOps.
+Can Patterns can include additional configuration and/or demo elements located in one or more additional private Git repositories.
+Patterns can include automation that deploys a known set of clusters and/or machines in a specific topology.
+Patterns can limit functionality/testing claims to specific platforms, topologies, and cluster/node sizes.
+Patterns can consume Operators from established partners (for example, Hashicorp Vault, and Seldon)
+Patterns can include managed clusters.
+Patterns can include details or automation for provisioning managed clusters, or rely on the admin to pre-provision them out-of-band.
+Patterns can also choose to model multi-cluster solutions as an uncoordinated collection of initial hub clusters.
+Imperative elements can interact with cluster state or external influences.
+`,url:"https://validatedpatterns.io/learn/implementation/",breadcrumb:"/learn/implementation/"},"https://validatedpatterns.io/learn/sandbox/":{title:"Validated Patterns - Sandbox tier",tags:[],content:`About the Validated Patterns Sandbox tier A pattern categorized under the sandbox tier provides you with an entry point to onboard to the Validated Patterns. The minimum requirement to qualify for the sandbox tier is that you must start with the patterns framework and include minimal documentation.
+Nominating a pattern for the sandbox tier The Validated Patterns team has a preference for empowering others, and not taking credit for their work.
+Where there is an existing application or a demonstration, 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 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.
+Requirements for the sandbox tier Consider these requirements for all sandbox tier.
+The requirements are categorized as follows:
+Must These are nonnegotiable, core requirements that must be implemented.
+Should These are important but not critical; their implementation enhances the pattern.
+Can These are optional or desirable features, but their absence does not hinder the implementation of a pattern.
+Must A sandbox pattern must continue to meet the following criteria to remain in the sandbox tier:
+A sandbox pattern must conform to the common technical implementation requirements.
+A sandbox pattern must be able to be deployed onto a freshly deployed OpenShift cluster without prior modification or tuning.
+A sandbox pattern must include a top-level README file that highlights the business problem and how the pattern solves it.
+A sandbox pattern must include an architecture drawing. The specific tool or format is flexible as long as the meaning is clear.
+A sandbox pattern must undergo an informal technical review by a community leader to ensure that it meets basic reuse standards.
+A 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. For example, not using a database as a message bus.
+As community leaders, contributions from within Red Hat might 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.
+A sandbox pattern must document their support policy.
+It is anticipated that most sandbox pattern 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.
+Can A sandbox pattern (including works-in-progress) can be hosted in the https://github.com/validatedpatterns-sandbox GitHub organization.
+A sandbox pattern can be listed on the https://validatedpatterns.io site.
+A sandbox pattern meeting additional criteria can be nominated for promotion to the Tested tier.
+`,url:"https://validatedpatterns.io/learn/sandbox/",breadcrumb:"/learn/sandbox/"},"https://validatedpatterns.io/learn/tested/":{title:"Validated Patterns - Tested tier",tags:[],content:`About the Validated Patterns Tested tier 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 Red Hat OpenShift Container Platform. 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).
+Nominating a a pattern for the tested tier If your pattern qualifies or meets the criteria for tested tier, submit your nomination to validatedpatterns@googlegroups.com.
+Each tested pattern represents an ongoing maintenance, support, and testing effort. Finite team capacity means that it is not possible for the team to take on this responsibility for all Validated Patterns.
+For this reason we have designed the tiers and our processes to facilitate this to occur outside of the team by any sufficiently motivated party, including other parts of Red Hat, partners, and even customers.
+In limited cases, the Validated Patterns team may consider taking on that work, however 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
+Requirements for the tested tier A tested patterns have deliverable and requirements in addition to those specified for the Sandbox tier.
+The requirements are categorized as follows:
+Must These are nonnegotiable, core requirements that must be implemented.
+Should These are important but not critical; their implementation enhances the pattern.
+Can These are optional or desirable features, but their absence does not hinder the implementation of a pattern.
+Must A tested pattern must continue to meet the following criteria to remain in the tested tier:
+A tested pattern must conform to the common technical implementation requirements.
+A tested pattern must be meaningful without specialized hardware, including flavors of architectures not explicitly supported.
+Qualification is a Validated Patterns Technical Oversight Committee (TOC) decision with input from the pattern owner.
+A tested pattern 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.
+A tested pattern must include a standardized architecture drawing, created with (or at least conforming to) the standard Validated Patterns tooling.
+A tested pattern must include a written guide for others to follow when demonstrating the pattern.
+A tested pattern 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: Validating an Industrial Edge Deployment.
+A tested pattern must nominate at least one currently supported Red Hat OpenShift Container Platform release to test against.
+A tested pattern must ensure the test plan passes at least once per quarter.
+A tested pattern must 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 Red Hat OpenShift Container Platform version. See testing artifacts.
+A tested pattern does not imply an obligation of support for partner or community operators by Red Hat or the pattern owner.
+Should A tested pattern should be broadly applicable.
+A tested pattern should focus on functionality not performance.
+Can Teams creating tested pattern can provide their own service level agreement (SLA).
+A technical document for Quality Engineering (QE) team that defines how to validate if the pattern has been successfully deployed and is functionally operational. For example, see Validating an Industrial Edge Deployment.
+A tested pattern meeting additional criteria can be nominated for promotion to the Maintained tier.
+`,url:"https://validatedpatterns.io/learn/tested/",breadcrumb:"/learn/tested/"},"https://validatedpatterns.io/learn/maintained/":{title:"Validated Patterns - Maintained tier",tags:[],content:`About the Validated Patterns Maintained tier A pattern categorized under the maintained tier implies that the pattern was known to be functional on all currently supported extended update support (EUS) versions of Red Hat OpenShift Container Platform. Qualifying for this tier might require additional work for the pattern’s owner who might be a partner or a sufficiently motivated subject matter expert (SME).
+Nominating a pattern for the maintained tier If your pattern qualifies or meets the criteria for maintained tier, submit your nomination to validatedpatterns@googlegroups.com.
+Each maintained pattern represents an ongoing maintenance, support, and testing effort. Finite team capacity means that it is not possible for the team to take on this responsibility for all Validated Patterns.
+For this reason we have designed the tiers and our processes to facilitate this to occur outside of the team by any sufficiently motivated party, including other parts of Red Hat, partners, and even customers.
+In limited cases, the Validated Patterns team may consider taking on that work, however, it is recommended that you contact the team at least 4 weeks prior to the end of a given quarter for the necessary work to be considered as part of the following quarter’s planning process.
+Requirements for the maintained tier The maintained patterns have deliverable and requirements in addition to those specified for the Tested tier.
+The requirements are categorized as follows:
+Must These are nonnegotiable, core requirements that must be implemented.
+Should These are important but not critical; their implementation enhances the pattern.
+Can These are optional or desirable features, but their absence does not hinder the implementation of a pattern.
+Must A maintained pattern must continue to meet the following criteria to remain in maintained tier:
+A maintained pattern must conform to the common technical implementation requirements.
+A maintained pattern must only make use of components that are either supported, or easily substituted for supportable equivalents, for example, HashiCorp vault which has community and enterprise variants.
+A maintained pattern must not rely on functionality in tech-preview, or hidden behind feature gates.
+A maintained pattern must have their architectures reviewed by a representative of each Red Hat product they consume to ensure consistency with the product teams\` intentions and roadmaps. Your patterns SME (eg. services rep) can help coordinate this.
+A maintained pattern must include a link to a hosted presentation (Google Slides or similar) intended to promote the solution. The focus should be on the architecture and business problem being solved. No customer, or otherwise sensitive, information should be included.
+A maintained pattern must include test plan automation that runs on every change to the pattern, or a schedule no less frequently than once per week.
+A maintained pattern must be tested on all currently supported Red Hat OpenShift Container Platform extended update support (EUS) releases.
+A maintained pattern must fix breakage in timely manner.
+A maintained pattern must document their support policy.
+The individual products used in a Validated Patterns are backed by the full Red Hat support experience conditional on the customer’s subscription to those products, and the individual products\`s support policy.
+Additional components in a Validated Patterns that are not supported by Red Hat; for example, Hashicorp Vault, and Seldon Core, require a customer to obtain support from that vendor directly.
+The Validated Patterns team is will try to address any problems in the Validated Patterns Operator, and in the common Helm charts, but cannot not offer any SLAs at this time.
+The maintained patterns do not imply an obligation of support for partner or community Operators by Red Hat.
+Can If you are creating Validated Patterns, you can provide your own SLA.
+`,url:"https://validatedpatterns.io/learn/maintained/",breadcrumb:"/learn/maintained/"},"https://validatedpatterns.io/patterns/multicloud-gitops-amx-rhoai/mcg-amx-rhoai-imperative-actions/":{title:"Imperative actions",tags:[],content:` Using kubernetes cronjobs to apply imperative actions There is currently no way within Argo CD to apply an imperative action against a cluster. However, you can declaratively apply changes to a cluster using kubernetes cronjob resources. Customers can use their Ansible playbooks to take action against a cluster if necessary.
+The authors of the Ansible playbooks and roles must ensure that the playbooks are idempotent because they get applied through cronjobs which are set to run every 10 minutes.
+Adding your playbooks to the pattern requires the following:
+Move your Ansible configurations to the appropriate directory under Ansible in your forked repository.
+Define your job as a list, for example:
+imperative: # NOTE: We *must* use lists and not hashes. As hashes lose ordering once parsed by helm # The default schedule is every 10 minutes: imperative.schedule # Total timeout of all jobs is 1h: imperative.activeDeadlineSeconds # imagePullPolicy is set to always: imperative.imagePullPolicy # For additional overrides that apply to the jobs, please refer to the README located in # the top level of this repository. jobs: - name: regional-ca # Ansible playbook to be run playbook: ansible/playbooks/on-hub-get-regional-ca.yml # per playbook timeout in seconds timeout: 234 # verbosity: &#34;-v&#34; Additional job customizations The pattern includes override parameters to provide further customization. Refer to the list below for the available overrides.
+imperative: jobs: [] # This image contains Ansible + kubernetes.core by default and is used to run the jobs image: registry.redhat.io/ansible-automation-platform-22/ee-supported-rhel8:latest namespace: &#34;imperative&#34; # configmap name in the namespace that will contain all helm values valuesConfigMap: &#34;helm-values-configmap&#34; cronJobName: &#34;imperative-cronjob&#34; jobName: &#34;imperative-job&#34; imagePullPolicy: Always # This is the maximum timeout of all the jobs (1h) activeDeadlineSeconds: 3600 # By default we run this every 10minutes schedule: &#34;*/10 * * * *&#34; # Schedule used to trigger the vault unsealing (if explicitly enabled) # Set to run every 9 minutes in order for load-secrets to succeed within # a reasonable amount of time (it waits up to 15 mins) insecureUnsealVaultInsideClusterSchedule: &#34;*/9 * * * *&#34; # Increase Ansible verbosity with &#39;-v&#39; or &#39;-vv..&#39; verbosity: &#34;&#34; serviceAccountCreate: true # service account to be used to run the cron pods serviceAccountName: imperative-sa clusterRoleName: imperative-cluster-role clusterRoleYaml: &#34;&#34; roleName: imperative-role roleYaml: &#34;&#34; `,url:"https://validatedpatterns.io/patterns/multicloud-gitops-amx-rhoai/mcg-amx-rhoai-imperative-actions/",breadcrumb:"/patterns/multicloud-gitops-amx-rhoai/mcg-amx-rhoai-imperative-actions/"},"https://validatedpatterns.io/patterns/ansible-edge-gitops-kasten/troubleshooting/":{title:"Troubleshooting",tags:[],content:`Troubleshooting Our Issue Tracker Please file an issue if you see a problem!
+`,url:"https://validatedpatterns.io/patterns/ansible-edge-gitops-kasten/troubleshooting/",breadcrumb:"/patterns/ansible-edge-gitops-kasten/troubleshooting/"},"https://validatedpatterns.io/patterns/ansible-edge-gitops/troubleshooting/":{title:"Troubleshooting",tags:[],content:`Troubleshooting Our Issue Tracker Please file an issue if you see a problem!
+`,url:"https://validatedpatterns.io/patterns/ansible-edge-gitops/troubleshooting/",breadcrumb:"/patterns/ansible-edge-gitops/troubleshooting/"},"https://validatedpatterns.io/learn/values-files/":{title:"Values Files",tags:[],content:` Exploring values A value represents a specific configuration or parameter that influences the behavior of a validated pattern. These values may range from simple settings like port numbers to more complex elements such as host names and DNS entries. Their role is to ensure that validated patterns adapt to diverse needs and scenarios, whether they involve straightforward settings or more complex configurations. Values are instrumental in ensuring the efficient and seamless operation of validated patterns.
+Benefits of using values files Values files offer a flexible and modular approach to deploying validated patterns, providing key advantages:
+Adaptability: Empowers adjustment of validated patterns or applications to diverse deployment scenarios without direct modifications to the underlying codebase.
+Maintainability: Streamlines the process of updating and managing configurations, promoting maintainability and reducing the likelihood of errors during deployment.
+Integration of values files in validated patterns Validated patterns use values files to dynamically adapt to different deployment scenarios. During deployment, the pattern references the values file to fetch specific configurations, making the deployment process versatile and adaptable.
+Example of a value in a values file
+applications: coffeeshop-test: name: quarkuscoffeeshop-demo namespace: quarkuscoffeeshop-demo project: quarkuscoffeeshop-demo path: charts/store/quarkuscoffeeshop-charts overrides: - name: projectnamespace value: quarkuscoffeeshop-demo - name: Release.release-namespace value: quarkuscoffeeshop-demo - name: storeid value: TEST In this example, the coffeeshop-test application has specific overrides, such as setting the projectnamespace to quarkuscoffeeshop-demo, the Release.release-namespace to quarkuscoffeeshop-demo, and the storeid to TEST. These values can be easily adjusted based on the desired configuration for the application, showcasing the flexibility provided by values files in tailoring deployments to specific requirements.
+Outline of a basic values file In a values file, each variable declares an element with a default value, influencing Helm templates and guiding validated patterns. As files or overrides enter the rendering pipeline, they replace default values in the values files, following the principle that the last value takes precedence for adaptability.
+The three-fold distinction in validated patterns, &#34;Global,&#34; &#34;Main,&#34; and &#34;ClusterGroup,&#34; practically applies the Helm override scheme. While &#34;main&#34; and &#34;global&#34; terms are used interchangeably, Helm differentiates by allowing &#34;global&#34; variables to extend to sub-charts, ensuring comprehensive configuration access. Values files, structured in free-form YAML, provide flexibility for any YAML variable type and are organized into Global, Main, and ClusterGroup configurations.
+In Validated patterns, values files follow Helm rules, but the &#34;global&#34; and &#34;ClusterGroup&#34; sections have distinct meanings within this framework.
+Increasingly, more value files are designed solely for overriding base chart values. These files may not always have &#34;ClusterGroup,&#34; &#34;Main,&#34; or &#34;Global&#34; values. The decision to include these sections depends on the specific overrides required for each case.
+Key sections of values files:
+Global Global values refer to configuration settings shared across multiple charts within a deployment. These values are distributed among various charts to avoid redundancy and configuration setting repetition, promoting consistency. Each pattern includes a values-global.yaml file, which contains configurations that are automatically incorporated into the application specification processed by the GitOps operator.
+ClusterGroup The ClusterGroup holds a specific significance within validated patterns. It defines clusters that are anticipated to share nearly identical configurations, serving a common architectural purpose. A ClusterGroup may consist of one or many members. Conventionally, there is a main ClusterGroup defined in main.clusterGroupName in values-global.yaml, acting as the hub or starting point for each pattern. Additional ClusterGroups can be managed by the main ClusterGroup through tools like Red Hat Advanced Cluster Management (RHACM).
+Not all value files contain a ClusterGroup section; instead values-global sets the starting point, and these value files can subsequently define managed clusters.
+`,url:"https://validatedpatterns.io/learn/values-files/",breadcrumb:"/learn/values-files/"},"https://validatedpatterns.io/patterns/multicloud-gitops-amx-rhoai/mcg-amx-rhoai-ideas-for-customization/":{title:"Ideas for customization",tags:[],content:` Ideas for customization About customizing the pattern Multicloud GitOps pattern One of the major goals of the Validated Patterns development process is to create modular, customizable demos. The Multicloud Gitops is just an example of a pattern managing multiple clusters in a GitOps fashion. It contains a very simple config-demo application, which prints out a secret that was injected into the vault through an out-of-band mechanism.
+You can customize this demo in different ways.
+Split the config-demo across hub and regional clusters Currently hub and regional clusters are reusing the exact same helm chart found at charts/all/config-demo. The first customization step could be to split the demo app in two separate charts: one in charts/hub/config-demo and one in charts/region/config-demo. Once charts/all/config-demo has been copied to charts/hub/config-demo and charts/region/config-demo, you need to include them in the respective values-hub.yaml and values-region-one.yaml, respectively.
+After completing this configuration, you can start customizing the two apps and make them output a different web page entirely depending if the pod is running on the hub or on the cluster.
+Rest API addition After splitting the charts, you could implement a small REST API server on the hub. This API could serve read-only values out to anyone and could provide some update write-APIs only if the client provides a secret, for example, by using the X-API-KEY mechanism. You can tweak the config-demo application to communicate to the hub and use a vault-injected secret as the X-API-KEY. So the hub would possess the key through the External-Secrets generated kubernetes secret and the regional app would possess that same secret via the RHACM policy pushing out secrets via the {{hub fromSecret}} mechanism.
+`,url:"https://validatedpatterns.io/patterns/multicloud-gitops-amx-rhoai/mcg-amx-rhoai-ideas-for-customization/",breadcrumb:"/patterns/multicloud-gitops-amx-rhoai/mcg-amx-rhoai-ideas-for-customization/"},"https://validatedpatterns.io/learn/secrets/":{title:"Secrets",tags:[],content:`Secrets Secret Management One area that has been impacted by a more automated approach to security is in the secret management. DevOps (and DevSecOps) environments require the use of many different services:
+Code repositories
+GitOps tools
+Image repositories
+Build pipelines
+All of these services require credentials. (Or should do!) And keeping those credentials secret is very important. E.g. pushing your credentials to your personal GitHub/GitLab repository is not a secure solution.
+While using a file based secret management can work if done correctly, most organizations opt for a more enterprise solution using a secret management product or project. The Cloud Native Computing Foundation (CNCF) has many such projects. The Validated Patterns project has started with Hashicorp Vault secret management product but we look forward to other project contributions.
+`,url:"https://validatedpatterns.io/learn/secrets/",breadcrumb:"/learn/secrets/"},"https://validatedpatterns.io/learn/faq/":{title:"FAQ",tags:[],content:`FAQ What is a Validated Pattern? Validated Patterns are collections of applications (in the ArgoCD sense) that demonstrate aspects of hub/edge computing that seem interesting and useful. Validated Patterns will generally have a hub or centralized component, and an edge component. These will interact in different ways.
+Many things have changed in the IT landscape in the last few years - containers and kubernetes have taken the industry by storm, but they introduce many technologies and concepts. It is not always clear how these technologies and concepts play together - and Validated Patterns is our effort to show these technologies working together on non-trivial applications in ways that make sense for real customers and partners to use.
+The first Validated Pattern is based on MANUela, an application developed by Red Hat field associates. This application highlights some interesting aspects of the industrial edge in a cloud-native world - the hub component features pipelines to build the application, a &#34;twin&#34; for testing purposes, a central data lake, an s3 component to gather data from the edge installations (which are factories in this case). The edge component has machine sensors, which are responsible for only gathering data from instrumented line devices and shares them via MQTT messaging. The edge also features Seldon, an AI/ML framework for making predictions, a custom Node.js application to show data in real time, and messaging components supporting both MQTT and Kafka protocols. The local applications use MQTT to retrieve data for display, and the Kafka components move the data to the central hub for storage and analysis.
+We are actively developing new Validated Patterns. Watch this space for updates!
+How are they different from XYZ? Many technology demos can be very minimal - such demos have an important place in the ecosystem to demonstrate the intent of an individual technology. Validated Patterns are meant to demonstrate groups of technologies working together in a cloud native way. And yet, we hope to make these patterns general enough to allow for swapping application components out — for example, if you want to swap out ActiveMQ for RabbitMQ to support MQTT - or use a different messaging technology altogether, that should be possible. The other components will require reconfiguration.
+What technologies are used? Key technologies in the stack for Industrial Edge include:
+Red Hat OpenShift Container Platform
+Red Hat Advanced Cluster Management
+Red Hat OpenShift GitOps (based on ArgoCD)
+Red Hat OpenShift Pipelines (based on tekton)
+Red Hat Integration - AMQ Broker (ActiveMQ Artemis MQTT)
+Red Hat Integration - AMQ Streams (Kafka)
+Red Hat Integration - Camel K
+Seldon Operator
+In the future, we expect to further use Red Hat OpenShift, and expand the integrations with other elements of the ecosystem. How can the concept of GitOps integrate with a fleet of devices that are not running Kubernetes? What about integrations with baremetal or VM servers? Sounds like a job for Ansible! We expect to tackle some of these problems in future patterns.
+How are they structured? Validated Patterns come in parts - we have a common repository with logic that will apply to multiple patterns. Layered on top of that is our first pattern - industrial edge. This layout allows for individual applications within a pattern to be swapped out by pointing to different repositories or branches for those individual components by customizing the values files in the root of the repository to point to different branches or forks or even different repositories entirely. (At present, the repositories all have to be on github.com and accessible with the same token.)
+The common repository is primarily concerned with how to deploy the GitOps operator, and to create the namespaces that will be necessary to manage the pattern applications.
+The pattern repository has the application-specific layout, and determines which components are installed in which places - hub or edge. The pattern repository also defines the hub and edge locations. Both the hub and edge are expected to have multiple components each - the hub will have pipelines and the CI/CD framework, as well as any centralization components or data analysis components. Edge components are designed to be smaller as we do not need to deploy Pipelines or the test and staging areas to the Edge.
+Each application is described as a series of resources that are rendered into GitOps (ArgoCD) via Helm and Kustomize. The values for these charts are set by values files that need to be &#34;personalized&#34; (with your local cluster values) as the first step of installation. Subsequent pushes to the gitops repository will be reflected in the clusters running the applications.
+Who is behind this? Today, a team of Red Hat engineers including Andrew Beekhof (@beekhof), Lester Claudio (@claudiol), Martin Jackson (@mhjacks), William Henry (@ipbabble), Michele Baldessari (@mbaldessari), Jonny Rickard (@day0hero) and others.
+Excited or intrigued by what you see here? We’d love to hear your thoughts and ideas! Try the patterns contained here and see below for links to our repositories and issue trackers.
+How can I get involved? Try out what we’ve done and submit issues to our issue trackers.
+We will review pull requests to our pattern repositories.
+`,url:"https://validatedpatterns.io/learn/faq/",breadcrumb:"/learn/faq/"},"https://validatedpatterns.io/blog/2024-11-07-clustergroup-sequencing/":{title:"Additional Sequencing Capabilities in clusterGroup",tags:[],content:` Preamble Ideally, all subscriptions installed in Kubernetes and OpenShift will envision all potential conflicts, and will deal gracefully with situations when other artifacts installed on the cluster require reconfiguration or different behavior.
+Architecturally, we have always said that we prefer eventual consistency, by which we mean that in the presence of error conditions the software should be prepared to retry until it can achieve the state it wants to be in. In practice that means we should be able to install a number of artifacts at the same time, and the artifacts themselves should be able to achieve the declarative state expressed in their installation. But some software does not work this way (even if its stated goal and intention is to work this way) and it is advantageous to be able to impose order of events to create better situations for installation. For example, even well-crafted software can be subject to different kinds of timing problems, as we will illustrate below.
+Because of this, we have introduced a set of capabilties to the Validated Patterns clusterGroup chart to enforce sequencing on the objects in a declarative and Kubernetes-native way.
+In this blog post, we will explore the various options that are available as of today in the Validated Patterns framework for enforcing sequencing for subscriptions. Inside applications, Validated Patterns has supported these primitives since the first release of Medical Diagnosis, and will continue to do so.
+Since the focus of Validated Patterns on OpenShift is the OpenShift GitOps Operator, these capabilities rely on the use of resource hooks, described in the upstream docs here.
+Within the framework, we support resource hooks in three ways:
+Supporting annotations directly on subscription objects at the clusterGroup level
+Exposing a new optional sequenceJob attribute on subscriptions that uses resource hooks
+Exposing a new top-level clusterGroup object, extraObjects, that allows users full control of creating their own resource hooks.
+These features are available in version 0.9.9 and later of the Validated Patterns clustergroup chart.
+Race Conditions: The Problem Timing issues are one of the key problems of distributed systems. One of the biggest categories of timing problems is race conditions. In our context, let’s say subscription A reacts to a condition in subscription B. Subscription A only checks on that condition during installation time. Thus, subscription A’s final state depends on when, exactly, subscription B was installed. Even if A and B were both installed at the same time, the normal variance of things like how quickly the software was downloaded could result in different parts of the installation being run at different times, and potentially different results.
+The ideal solution to this problem is for subscription B to always be watching for the presence of subscription A, and reconfiguring itself if it sees subscription A being installed. But if subscription B does not want to do this, or for some reason cannot do this, or even if a better fix is committed but not yet available, we want to have a set of practical solutions in the Validated Patterns framework.
+So, in the absence of an ideal fix - where all subscriptions are prepared to deal with all possible race outcomes - a very effective way of working around the problem is enforce ordering or sequencing of actions.
+The Specific Race Condition that led to this feature The specific case that gave rise to the development of this feature is a race condition between OpenShift Data Foundation (ODF) and OpenShift Virtualization (OCP-Virt), which will be fixed in a future release of OCP-Virt. The condition results when OCP-Virt, on installation, discovers a default storageclass, but then subsequently ODF is installed, which OCP-Virt has specific optimizations for, related to how images are managed for VM guests to be created. One way to workaround the race condition is to ensure that ODF completes creating its storageclasses before the OCP-Virt subscription is allowed to install.
+Sync-Waves and ArgoCD/OpenShift GitOps Resource Hooks The way that resource hooks are designed to work is by giving ordering hints, so that ArgoCD knows what order to apply resources in. The mechanism is described in the ArgoCD upstream docs here. When sync-waves are in use, all resouces in the same sync-wave have to be &#34;healthy&#34; before resources in the numerically next sync-wave are synced. This mechanism gives us a way of having ArgocD help us enforce order with objects that it manages.
+Solution 1: Sync-Waves for Subscriptions (and/or Applications) in clusterGroup The Validated Patterns framework now allows Kubernetes annotations to be added directly to subscription objects and application objects in the clusterGroup. ArgoCD uses annotations for Resource Hooks. The clustergoup chart now passes any annotations attached to subscriptions through to the subscription object(s) that the clustergroup chart creates. For example:
+openshift-virtualization: name: kubevirt-hyperconverged namespace: openshift-cnv channel: stable annotations: argocd.argoproj.io/sync-wave: &#34;10&#34; openshift-data-foundation: name: odf-operator namespace: openshift-storage annotations: argocd.argoproj.io/sync-wave: &#34;5&#34; will result in a subscription object that includes the annotations:
+apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: annotations: argocd.argoproj.io/sync-wave: &#34;10&#34; labels: app.kubernetes.io/instance: ansible-edge-gitops-hub operators.coreos.com/kubevirt-hyperconverged.openshift-cnv: &#34;&#34; name: kubevirt-hyperconverged namespace: openshift-cnv spec: channel: stable installPlanApproval: Automatic name: kubevirt-hyperconverged source: redhat-operators sourceNamespace: openshift-marketplace apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: annotations: argocd.argoproj.io/sync-wave: &#34;5&#34; labels: app.kubernetes.io/instance: ansible-edge-gitops-hub operators.coreos.com/odf-operator.openshift-storage: &#34;&#34; name: odf-operator namespace: openshift-storage spec: installPlanApproval: Automatic name: odf-operator source: redhat-operators sourceNamespace: openshift-marketplace With this configuration, any objects created with sync-waves lower than &#34;10&#34; must be healthy before the objects in sync-wave &#34;10&#34; sync. In particular, the odf-operator subscription must be healthy before the kubevirt-hyperconverged subscription will sync. Similarly, if we defined objects with higher sync-waves than &#34;10&#34;, all the resources with sync-waves higher than &#34;10&#34; will wait until the resources in &#34;10&#34; are healthy. If the subscriptions in question wait until their components are healthy before reporting they are healthy themselves, this might be all you need to do. In the case of this particular issue, it was not enough. But because all sequencing in ArgoCD requires the use of sync-wave annotations, adding the annotation to the subscription object will be necessary for using the other solutions.
+The sequencing of applications would work the same way, with the same format for adding annotations to the application stanzas in the clustergroup.
+Solution 2: The sequenceJob attribute for Subscriptions in clusterGroup In this situation, we have a subscription that installs an operator, but it is not enough for just the subscriptions to be in sync-waves. This is because the subscriptions install operators, and it is the action of the operators themselves that we have to sequence. In many of these kinds of situations, we can sequence the action by looking for the existence of a single resource. The new sequenceJob construct in subscriptions allows for this kind of relationship by creating a Job at the same sync-wave precedence as the subscription, and looking for the existence of a single arbitrary resource in an arbitrary namespace. The Job then waits for that resource to appear, and when it does, it will be seen as &#34;healthy&#34; and will allow future sync-waves to proceed.
+In this example, the ODF operator needs to have created a storageclass so that the OCP-Virt operators can use it as virtualization storage. If it does not find the kind of storage it wants, it will use the default storageclass instead, which may lead to inconsistencies in behavior. We can have the Validated Patterns framework create a mostly boilerplate job to look for the needed resource this way:
+openshift-virtualization: name: kubevirt-hyperconverged namespace: openshift-cnv channel: stable annotations: argocd.argoproj.io/sync-wave: &#34;10&#34; openshift-data-foundation: name: odf-operator namespace: openshift-storage sequenceJob: resourceType: sc resourceName: ocs-storagecluster-ceph-rbd annotations: argocd.argoproj.io/sync-wave: &#34;5&#34; Note the addition of the sequenceJob section in the odf-operator subscription block. This structure will result in the following Job being created alongside the subscriptions:
+apiVersion: batch/v1 kind: Job metadata: annotations: argocd.argoproj.io/hook: Sync argocd.argoproj.io/sync-wave: &#34;5&#34; labels: app.kubernetes.io/instance: ansible-edge-gitops-hub name: odf-operator-sequencejob namespace: openshift-operators spec: backoffLimit: 6 completionMode: NonIndexed completions: 1 manualSelector: false parallelism: 1 podReplacementPolicy: TerminatingOrFailed selector: matchLabels: batch.kubernetes.io/controller-uid: 3084075d-bc1f-4e23-b44d-a13c5d184a6a suspend: false template: metadata: creationTimestamp: null labels: batch.kubernetes.io/controller-uid: 3084075d-bc1f-4e23-b44d-a13c5d184a6a batch.kubernetes.io/job-name: odf-operator-sequencejob controller-uid: 3084075d-bc1f-4e23-b44d-a13c5d184a6a job-name: odf-operator-sequencejob spec: containers: - command: - /bin/bash - -c - | while [ 1 ]; do oc get sc ocs-storagecluster-ceph-rbd &amp;&amp; break echo &#34;sc ocs-storagecluster-ceph-rbd not found, waiting...&#34; sleep 5 done echo &#34;sc ocs-storagecluster-ceph-rbd found, exiting...&#34; exit 0 image: quay.io/hybridcloudpatterns/imperative-container:v1 imagePullPolicy: IfNotPresent name: odf-operator-sequencejob resources: {} terminationMessagePath: /dev/termination-log terminationMessagePolicy: File dnsPolicy: ClusterFirst restartPolicy: OnFailure schedulerName: default-scheduler securityContext: {} terminationGracePeriodSeconds: 30 Since the job is created in sync-wave &#34;5&#34; (which it inherits from the subscription it is attached to by default, though you can specify a different sync-wave if you prefer), this job must complete before sync-wave &#34;10&#34; starts. So the storageclass ocs-storagecluster-ceph-rbd must exist before OCP-Virt starts deploying, ensuring that it will be able to &#34;see&#34; and use that storageclass as its default virtualization storage class.
+Each subscription is permitted one sequenceJob. Each sequenceJob may have the following attributes:
+syncWave: Defaults to the subscription’s syncwave from annotations.
+resourceType: Resource kind for the resource to watch for.
+resourceName: Name of the resource to watch for.
+resourceNamespace: Namespace to watch for the resourceType and resourceName in.
+hookType: Any of the permissible ArgoCD Resource Hook types. Defaults to &#34;Sync&#34;.
+image: Image of the container to use for the job. Defaults to the Validated Patterns imperative image.
+command: Command to run inside the container, if the default is not suitable. This also enables you to specify multiple resources to watch for in the same job, or to look for a different condition altogether.
+disabled: Set this to true in an override if you wish to disable the sequenceJob for some reason (such as running on a different version of OpenShift or running on a different cloud platform).
+If the sequenceJob is not sufficient for your sequencing needs, we have a more generic interface that you can use that places no restrictions on the objects you can add, so you can use it to create different kinds of conditions.
+Solution 3: The extraObjects attribute in clusterGroup The most open-ended solution to the sequencing problem involves defining arbitrary objects under the extraObjects key for the clustergroup. Here is how you could do that using the example we have been using so far:
+extraObjects: wait-for-virt-storageclass: apiVersion: batch/v1 kind: Job metadata: name: wait-for-virt-storageclass annotations: argocd.argoproj.io/hook: Sync argocd.argoproj.io/sync-wave: &#34;5&#34; spec: parallelism: 1 completions: 1 template: spec: restartPolicy: OnFailure containers: - name: wait-for-storage-class image: quay.io/hybridcloudpatterns/imperative-container:v1 command: - /bin/bash - -c - | while [ 1 ]; do oc get sc ocs-storagecluster-ceph-rbd &amp;&amp; break echo &#34;Storage class ocs-storagecluster-ceph-rbd not found, waiting...&#34; sleep 5 done echo &#34;Storage class ocs-storagecluster-ceph-rbd found, exiting&#34; exit 0 Note that each extraObject has a key and value, and the value will be passed almost unaltered as a Kubernetes manifest. The special key disabled can be used to disable a specific, named extraObject from being created in subsequent overrides.
+Conclusion Here is hoping that you do not have sequencing problems to solve in your OpenShift deployments. But if you do, we hope you will find this feature in Validated Patterns useful. Please let us know, one way or the other, or if you find other uses, especially for the extraObjects feature.
+`,url:"https://validatedpatterns.io/blog/2024-11-07-clustergroup-sequencing/",breadcrumb:"/blog/2024-11-07-clustergroup-sequencing/"},"https://validatedpatterns.io/blog/":{title:"Blog",tags:[],content:`Find out the latest news about Validated Patterns.
+`,url:"https://validatedpatterns.io/blog/",breadcrumb:"/blog/"},"https://validatedpatterns.io/":{title:"Validated Patterns",tags:[],content:`
+Reference architectures with added value Validated Patterns are an evolution of how you deploy applications in a hybrid cloud. With a pattern, you can automatically deploy a full application stack through a GitOps-based framework. With this framework, you can create business-centric solutions while maintaining a level of Continuous Integration (CI) over your application.
+`,url:"https://validatedpatterns.io/",breadcrumb:"/"},"https://validatedpatterns.io/patterns/ansible-edge-gitops-kasten/":{title:"Ansible Edge GitOps with Veeam Kasten",tags:[],content:`Ansible Edge GitOps with Veeam Kasten Background Organizations are interested in accelerating their deployment speeds and improving delivery quality in their Edge environments, where many devices may not fully or even partially embrace the GitOps philosophy. Further, there are VMs and other devices that can and should be managed with Ansible. This pattern explores some of the possibilities of using an OpenShift-based Ansible Automated Platform deployment and managing edge devices, based on work done with a partner in the Chemical space.
+This pattern uses OpenShift Virtualization (the productization of KubeVirt) to provision VMs alongside Kubernetes-native workloads on the cluster. As VMs are inherently stateful workloads, a GitOps approach alone is not sufficient to recover an environment in the event of accidental data loss, malware attack, or infrastructure failure - especially in edge environments where infrastructure may be less resilient or subject to harsh environments. This example extends the standard Ansible Edge GitOps pattern to include automated deployment and configuration of Veeam Kasten, the #1 Kubernetes data protection and mobility solution.
+Solution elements How to use a GitOps approach to manage virtual machines, either in public clouds (limited to AWS for technical reasons) or on-prem OpenShift installations How to integrate AAP into OpenShift How to manage Edge devices using AAP hosted in OpenShift How to protect OpenShift Virtualzation VMs Red Hat Technologies Red Hat OpenShift Container Platform (Kubernetes) Red Hat Ansible Automation Platform (formerly known as &ldquo;Ansible Tower&rdquo;) Red Hat OpenShift GitOps (ArgoCD) OpenShift Virtualization (KubeVirt) Red Hat Enterprise Linux 8 Other Technologies this Pattern Uses Veeam Kasten Hashicorp Vault External Secrets Operator Inductive Automation Ignition Architecture Similar to other patterns, this pattern starts with a central management hub, which hosts the AAP and Vault components. Veeam Kasten is deployed on each cluster it protects, providing a self-contained solution ideal for edge deployments without dependencies on external infrastructure or SaaS management plane.
+Logical architecture Physical Architecture Other Presentations Featuring this Pattern Registration Required What&rsquo;s Next Getting Started: Deploying and Validating the Pattern `,url:"https://validatedpatterns.io/patterns/ansible-edge-gitops-kasten/",breadcrumb:"/patterns/ansible-edge-gitops-kasten/"},"https://validatedpatterns.io/patterns/":{title:"Patterns",tags:[],content:`Browse through available patterns and their respective documentation for deployment and operation. Filter patterns by type, industry, and product.
+`,url:"https://validatedpatterns.io/patterns/",breadcrumb:"/patterns/"},"https://validatedpatterns.io/blog/2024-10-12-disconnected/":{title:"Validated Patterns in a disconnected Network",tags:[],content:` Preamble This document provides a comprehensive guide on how to deploy a Validated Pattern, specifically the Multicloud GitOps solution on OpenShift 4.16, onto an OpenShift cluster that has been set up in a disconnected network environment. A disconnected network, in this context, refers to an infrastructure that is isolated from external internet access, which adds additional complexity to the deployment process.
+By following this guide, you will learn the necessary steps, best practices, and specific configurations required to successfully deploy Multicloud GitOps in such an environment. We will cover the prerequisite setup, key components involved, and how to manage the constraints posed by the lack of direct connectivity to external repositories and services. This ensures that even in a restricted, air-gapped network, the deployment of this validated pattern can be performed smoothly and securely.
+Requirements One or more openshift clusters deployed in a disconnected network
+An OCI-compliant registry that is accessible from the disconnected network (referred to as registry.internal.disconnected.net in this article)
+A Git Repository that is accessible from the disconnected network
+(Optional) A VM in the disconnected network where we run our commands
+We won’t cover here how to deploy openshift in a disconnected network, as there is more detailed documentation that can be found here
+Mirroring The first step needed to deploy a pattern is mirroring all the needed images. In most cases this is a very pattern-dependent process, so the exact list of needed images will depend on the pattern, on the openshift version and on the needed operators.
+In this example we use the tool oc mirror --v2 (note: it is currently in tech preview, but the experience is superior compared to the previous release). Here is an example of such a configuration file imageset-config.yaml:
+kind: ImageSetConfiguration apiVersion: mirror.openshift.io/v2alpha1 mirror: platform: graph: true channels: - name: stable-4.16 type: ocp operators: - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.16 packages: - name: lvms-operator - name: advanced-cluster-management channels: - name: release-2.11 - name: multicluster-engine channels: - name: stable-2.6 - name: openshift-gitops-operator channels: - name: gitops-1.13 - catalog: registry.redhat.io/redhat/community-operator-index:v4.16 packages: - name: patterns-operator additionalImages: - name: registry.redhat.io/ubi9/ubi-minimal:latest - name: registry.connect.redhat.com/hashicorp/vault:1.17.6-ubi - name: registry.access.redhat.com/ubi8/httpd-24:1-226 - name: ghcr.io/external-secrets/external-secrets:v0.10.2-ubi - name: registry.redhat.io/ansible-automation-platform-24/ee-supported-rhel9:latest # VP charts - name: quay.io/hybridcloudpatterns/acm:0.1.3 - name: quay.io/hybridcloudpatterns/clustergroup:0.9.5 - name: quay.io/hybridcloudpatterns/gitea:0.0.2 - name: quay.io/hybridcloudpatterns/golang-external-secrets:0.1.3 - name: quay.io/hybridcloudpatterns/hashicorp-vault:0.1.3 - name: quay.io/hybridcloudpatterns/utility-container:latest - name: quay.io/hybridcloudpatterns/imperative-container:v1 - name: quay.io/hybridcloudpatterns/pattern-install:0.0.3 - name: docker.io/gitea/gitea:1.21.11-rootless We can use this imageset-config.yaml file to mirror the needed images on our registry. We assume we have a folder (/var/cache/oc-mirror) where the tool can locally cache the downloaded images before pushing them to the internal registry. We copied the imageset-config.yaml in that folder:
+oc mirror --config=/var/cache/oc-mirror/imageset-config.yaml \\ --workspace file:///var/cache/oc-mirror/workspace \\ docker://registry.internal.disconnected.net --v2 Once this command completes the registry.internal.disconnected OCI registry will contain the mirrored images. The oc mirror command will generate a few yaml files that can be found under /var/cache/oc-mirror/workspace/working-dir/cluster-resources.
+We need to apply them to our cluster:
+cd /var/cache/oc-mirror/workspace/working-dir/cluster-resources oc apply -f cs-community-operator-index-v4-16.yaml \\ cs-redhat-operator-index-v4-16.yaml idms-oc-mirror.yaml \\ itms-oc-mirror.yaml Once these are applied the cluster will be able to fetch the images from the internal disconnected registry.
+Git repository changes Note that we assume here that the git folder you are working on has the origin remote pointing to the disconnected git server where you will be cloning the pattern from. To verify to which git server a remote is pointing to you can run the git remote -v command.
+We will need to tweak a couple of things so that the pattern is aware of which catalog sources in openshift contain the different images. Those names were defined in the previous mirroring step in the yaml files under /var/cache/oc-mirror/workspace/working-dir/cluster-resources.
+values-global.yaml:
+main: multiSourceConfig: enabled: true clusterGroupChartVersion: &#34;0.9.*&#34; helmRepoUrl: registry.internal.disconnected.net/hybridcloudpatterns patternsOperator: source: cs-community-operator-index-v4-16 gitops: operatorSource: cs-redhat-operator-index-v4-16 values-hub.yaml:
+acm: mce_operator: source: cs-redhat-operator-index-v4-16 clusterGroup: subscriptions: acm: name: advanced-cluster-management namespace: open-cluster-management channel: release-2.11 source: cs-redhat-operator-index-v4-16 Deploy the pattern At this point we can clone Multicloud Gitops on to a VM that lives in the disconnected network and deploy the pattern. The only thing we need to do first is to point the installation script to the mirrored helm chart inside the disconnected registry.
+# Points to the mirrored VP install chart export PATTERN_DISCONNECTED_HOME=registry.internal.disconnected.net/hybridcloudpatterns ./pattern.sh make install After a while the cluster will converge to its desired final state and the MultiCloud Gitops pattern will be installed successfully.
+`,url:"https://validatedpatterns.io/blog/2024-10-12-disconnected/",breadcrumb:"/blog/2024-10-12-disconnected/"},"https://validatedpatterns.io/patterns/coco-pattern/":{title:"Confidential Containers pattern",tags:[],content:`About coco-pattern Confidential computing is a technology for securing data in use. It uses a Trusted Execution Environment provided within the hardware of the processor to prevent access from others who have access to the system. Confidential containers is a project to standardize the consumption of confidential computing by making the security boundary for confidential computing to be a Kubernetes pod. [Kata containers](https://katacontainers.io/) is used to establish the boundary via a shim VM.
+A core goal of confidential computing is to use this technology to isolate the workload from both Kubernetes and hypervisor administrators.
+This pattern uses Red Hat OpenShift sandbox containers to deploy and configure confidential containers on Microsoft Azure.
+It deploys three copies of &#39;Hello OpenShift&#39; to demonstrate some of the security boundaries that enforced with confidential containers.
+Requirements An an azure account with the required access rights
+An OpenShift cluster, within the Azure environment updated beyond 4.16.10
+Security considerations This pattern is a demonstration only and contains configuration that is not best practice
+The default configuration deploys everything in a single cluster for testing purposes. The RATS architecture mandates that the Key Broker Service (e.g. Trustee) is in a trusted security zone.
+The Attestation Service has wide open security policies.
+Future work Deploying the environment the &#39;Trusted&#39; environment including the KBS on a separate cluster to the secured workloads
+Deploying to alternative environments supporting confidential computing including bare metal x86 clusters; IBM Cloud; IBM Z
+Finishing the sample AI application
+Architecture Confidential Containers typically has two environments. A trusted zone, and an untrusted zone. In these zones, Trustee, and the sandbox container operator are deployed, respectively.
+For demonstration purposes the pattern currently is converged on one cluster**
+References OpenShift sandboxed containers documentation
+OpenShift confidential containers solution blog
+`,url:"https://validatedpatterns.io/patterns/coco-pattern/",breadcrumb:"/patterns/coco-pattern/"},"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/":{title:"The Slimming of Common",tags:[],content:` Preamble Historically Validated Patterns, shipped all the helm charts and all the ansible code needed to deploy a pattern within the git repository of the pattern itself. The common subfolder in any pattern is a git subtree containing all of the common repository at a certain point in time. Some thoughts around the choice of git subtrees can be found here
+While having common in a git subtree in every pattern repositories has served us fairly well, it came with a number of trade-offs and less than ideal aspects:
+Most people are not really familiar with git subtrees and updating common was fairly cumbersome The pieces inside common (helm charts, ansible &amp; scripts) could not be updated independently Folks would just change the local common folder and not submit changes to the upstream repository, ultimately causing merge conflicts when updating common or when they eventually merged downstream
+At the time ArgoCD did not support multi-source so we did not really have many other choices other than shipping the whole of common as a folder. Now the multi source feature has become quite stable and it is possible to ship your values overrides for argo in one git repository and your helm charts in another repository (be it in a git repository, in a helm repository or even in an OCI-compliant registry).
+So the time has come for us to move all the charts out in their own repositories and while we’re at it we can also move ansible into its own collection. This makes it so that common is really just a collection of scripts to invoke the initial deployment of a pattern via CLI. The need to update the common subtree will be reduced a lot, the charts will be more self-contained and it will be a lot easier to update to newer versions.
+How to update a pattern to the slimmed down common First of all we need to update common to the latest version available upstream from the main branch. This can be done as follows:
+# Clone the pattern&#39;s repository gh repo clone validatedpatterns/multicloud-gitops # In the patterns&#39; repository add the common remote cd multicloud-gitops git remote add -f common https://github.com/validatedpatterns/common # Create a &#39;slimming&#39; branch where we will be working git checkout -b slimming # Update common from the main branch git merge -s subtree -Xtheirs -Xsubtree=common common/main At this point the pattern’s slimming branch has the slimmed down version of common.
+Then make sure you are using multisource for the clustergroup chart and use the 0.9.* chart.
+Note that by default, when unspecified the default clustergroup chart version when using multisource is 0.8.*.
+Set the following in values-global.yaml:
+main: multiSourceConfig: enabled: true clusterGroupChartVersion: 0.9.* Migrate the VP charts in your values-*.yaml to the multisource ones. So in multicloud-gitops for example:
+Old application description (for the non-slimmed down version of common):
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: common/acm New way of doing it:
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub chart: acm chartVersion: 0.1.* Do the above for all the applications having a path that points to common/&lt;…​&gt; Change any imperative job that references common to the playbook referenced in the collection
+Old way:
+imperative: jobs: - name: hello-world playbook: common/ansible/playbooks/hello-world/hello-world.yaml New way:
+imperative: jobs: - name: hello-world playbook: rhvp.cluster_utils.hello_world After the above changes are implemented the pattern is not using any helm charts nor ansible bits from common.
+How to reference another external chart If you need to reference a helm chart that is not in the validated patterns chart helm repository, you can simply point to another one. For example:
+clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
+The clustergroup chart. Tweak values-global.yaml as follows:
+spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+PreReqs and Assumptions Deploying HyperShift clusters requires the following:
+Resource Default Path Description hcp
+/usr/local/bin
+https://developers.redhat.com/content-gateway/rest/browse/pub/mce/clients/hcp-cli
+aws cli
+/usr/bin/aws
+dnf install awscli2
+oc
+/usr/bin/oc
+https://mirror.openshift.com/pub/openshift-v4/clients/ocp/stable/
+Podman
+Download
+dnf install podman
+Additionally, you will need:
+An openshift cluster that has the multicluster-engine operator deployed and configured
+You are logged into your management cluster with an appropriately credentialed user
+Instead of installing these software components locally would be to use the utility container podman pull quay.io/hybridcloudpatterns/utility-container:latest Create a cluster Before you create a cluster you will need to generate a STS token for AWS aws sts get-session-token --output json &gt; sts-creds.json hcp create cluster aws \\ --name &lt;cluster_name&gt; \\ --infra-id &lt;cluster_name&gt; \\ --sts-creds /path/to/your/sts-cred.json \\ --pull-secret /path/to/your/pullsecret.json \\ --region us-west-2 \\ --instance-type m5.xlarge \\ --node-pool-replicas=1 \\ --role-arn arn:aws:iam::123456789012:role/hcp_cli_role \\ --base-domain example.com When is the cluster ready? The hostedCluster creation process takes about 15 minutes to complete. There are multiple ways to determine the state of your cluster. You can manually check the resource state, or you can use the examples below to wait for the resources to change to an available state.
+oc get -n clusters hc,np,managedclusters Cluster is NOT READY #hostedCluster NAME VERSION KUBECONFIG PROGRESS AVAILABLE PROGRESSING MESSAGE hostedcluster.hypershift.openshift.io/&lt;cluster_name&gt; &lt;cluster_name&gt;-admin-kubeconfig Partial True False The hosted control plane is available #nodePools NAME CLUSTER DESIRED NODES CURRENT NODES AUTOSCALING AUTOREPAIR VERSION UPDATINGVERSION UPDATINGCONFIG MESSAGE nodepool.hypershift.openshift.io/&lt;cluster_name&gt;-us-west-2a &lt;cluster_name&gt; 1 1 False False 4.16.12 #managedclusters NAME HUB ACCEPTED MANAGED CLUSTER URLS JOINED AVAILABLE AGE managedcluster.cluster.open-cluster-management.io/&lt;cluster_name&gt; true https://a06f2548e7edb4fcea2e993d8e5da2df-e89c361840368138.elb.us-east-2.amazonaws.com:6443 True True 7m25s Cluster is READY #hostedClusters NAME VERSION KUBECONFIG PROGRESS AVAILABLE PROGRESSING MESSAGE hostedcluster.hypershift.openshift.io/&lt;cluster_name&gt; 4.16.12 &lt;cluster_name&gt;-admin-kubeconfig Completed True False The hosted control plane is available #nodePools NAME CLUSTER DESIRED NODES CURRENT NODES AUTOSCALING AUTOREPAIR VERSION UPDATINGVERSION UPDATINGCONFIG MESSAGE nodepool.hypershift.openshift.io/&lt;cluster_name&gt;-us-west-2a &lt;cluster_name&gt; 1 1 False False 4.16.12 NAME HUB ACCEPTED MANAGED CLUSTER URLS JOINED AVAILABLE AGE managedcluster.cluster.open-cluster-management.io/&lt;cluster_name&gt; true https://a06f2548e7edb4fcea2e993d8e5da2df-e89c361840368138.elb.us-east-2.amazonaws.com:6443 True True 17m Use the wait-for subcommand to watch for the resource state change
+#hostedClusters oc wait hc/&lt;cluster_names&gt; --for condition=available -n clusters --timeout 900s #nodePools oc wait np/test2-us-west-2a --for condition=ready -n clusters --timeout 900s #managedclusters oc wait --for condition=ManagedClusterConditionAvailable managedclusters/&lt;cluster_name&gt; --timeout 900s When completed you will see output similar to the following:
+#hostedClusters hostedcluster.hypershift.openshift.io/&lt;cluster_names&gt; condition met #nodePools nodepool.hypershift.openshift.io/&lt;cluster_name&gt;-us-west-2a condition met #managedclusters managedcluster.cluster.open-cluster-management.io/&lt;cluster_name&gt; condition met How do I get the kubeadmin password Each cluster’s kubeadmin secret is stored in the clusters-&lt;cluster_name&gt; namespace unless defined elsewhere.
+oc get secret kubeadmin-password -n clusters-&lt;cluster_name&gt; NAME TYPE DATA AGE kubeadmin-password Opaque 1 9m48s oc extract secret/kubeadmin-password -n clusters-&lt;cluster_name&gt; --keys=password --to=- # password vnkDn-xnmdr-qFdyA-GmQZD How do I get the kubeconfig to the managedcluster Use the below code snippet to create the kubeconfig for your cluster:
+This will get the admin kubeconfig for your cluster and save it to a file in the /tmp directory. hcp create kubeconfig --name &lt;cluster_name&gt; &gt; /tmp/&lt;cluster_name&gt;.kube How do I get my cluster openshift console address from the cli? oc get hc/&lt;cluster_name&gt; -n clusters -o jsonpath=&#39;{.status.controlPlaneEndpoint.host}&#39; How do I get my cluster infraID? oc get -o jsonpath=&#39;{.spec.infraID}&#39; hostedcluster &lt;cluster-name&gt; -n clusters How do I scale my nodepools? Get the available nodepools:
+oc get nodepools -n clusters Available nodepools NAME CLUSTER DESIRED NODES CURRENT NODES AUTOSCALING AUTOREPAIR VERSION UPDATINGVERSION UPDATINGCONFIG MESSAGE &lt;cluster_name&gt;-us-west-2a &lt;cluster_name&gt; 1 1 False False 4.15.27 Use oc scale to scale up the total number of nodes
+oc scale --replicas=2 nodepools/&lt;nodepool_name&gt; -n clusters After a few minutes the nodepool will scale up the number of compute resources in the nodepool
+NAME CLUSTER DESIRED NODES CURRENT NODES AUTOSCALING AUTOREPAIR VERSION UPDATINGVERSION UPDATINGCONFIG MESSAGE &lt;cluster_name&gt;-us-west-2a &lt;cluster_name&gt; 2 2 False False 4.15.27 What region is a managedcluster deployed to? oc get -o jsonpath=&#39;{.spec.platform.aws.region}&#39; hostedcluster &lt;cluster-name&gt; -n clusters What OpenShift versions are supported in Hosted Control Planes? oc get -o yaml cm supported_versions -n hyperShift Supported Versions apiVersion: v1 data: supported-versions: &#39;{&#34;versions&#34;:[&#34;4.16&#34;,&#34;4.15&#34;,&#34;4.14&#34;,&#34;4.13&#34;]}&#39; kind: ConfigMap metadata: creationTimestamp: &#34;2024-05-10T23:53:07Z&#34; labels: hypershift.openshift.io/supported-versions: &#34;true&#34; name: supported-versions namespace: hypershift resourceVersion: &#34;120388899&#34; uid: f5253d56-1a4c-4630-9b01-ee9b16177c76 Delete a cluster Deleting a cluster follows the same general process as creating a cluster. In addition to deleting the cluster using the hcp binary - we also need to delete the managedcluster resource.
+Deleting a Cluster hcp destroy cluster aws \\ --name &lt;cluster_name&gt; \\ --infra-id &lt;cluster_name&gt; \\ --region us-west-2 \\ --sts-creds /path/to/your/sts-creds.json \\ --base-domain example.com \\ --role-arn arn:aws:iam::123456789012:role/hcp_cli_role You will also need to delete the managedcluster resource oc delete managedcluster &lt;cluster_name&gt; Conclusion Use this blog as a practical guide for creating, deleting and managing your hostedCluster resources using the Hosted Control Planes feature!
+`,url:"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/",breadcrumb:"/blog/2024-09-13-using-hypershift/"},"https://validatedpatterns.io/blog/2024-08-30-push-secrets/":{title:"Pushing secrets",tags:[],content:`Pushing Secrets to HashiCorp Vault With this post we&rsquo;d like to Introduce a powerful new feature: Push Secrets Across Nodes and Namespaces.
+Overview We’re excited to announce a new feature that enhances the flexibility and security of your secret management workflows: you can now use the secret/pushsecrets vault path to push secrets from any node or any namespace to Vault. This feature allows secrets to be securely retrieved from a different namespace or even a different cluster node, making it easier to manage and distribute sensitive data across your infrastructure.
+Once stored in the Vault, these secrets can be accessed from either a different namespace or a different cluster node, providing a seamless way to manage secrets across a distributed environment.
+How It Works To illustrate how this feature works, let’s walk through a simple example where we push an existing kubernetes secret called existing-secret into the Vault using a PushSecret resource. The existing secret could be the following:
+apiVersion: v1 kind: Secret metadata: name: existing-secret namespace: hello-world data: bar: YmFyCg== # The secret field we are interested in pushing into the vault foo: .... And here is the PushSecret resource that will fetch the bar key from the existing secret above and push it into the vault.
+apiVersion: external-secrets.io/v1alpha1 kind: PushSecret metadata: name: pushsecret namespace: hello-world spec: data: - conversionStrategy: None match: remoteRef: remoteKey: pushsecrets/testme # the remote vault path property: baz # the key in the path defined above inside the vault secretKey: bar # The property of the local \`existing-secret\` secret that will be pushed to \`pushsecrets/testme/baz\` in the vault deletionPolicy: Delete refreshInterval: 10s secretStoreRefs: - kind: ClusterSecretStore name: vault-backend selector: secret: name: existing-secret updatePolicy: Replace In this example, the PushSecret resource is defined in the hello-world namespace and it will take the key bar of the k8s secret called existing-secret and push it to Vault in the pushsecrets/testme path and ultimately it will be copied under the baz key/property inside vault.
+Here is some more info on the other yaml fields:
+deletionPolicy Determines what happens to the secret when the PushSecret is deleted. In this case, the secret will also be deleted from the Vault. refreshInterval Sets how often the secret will be refreshed. This is set to 10 seconds in the example, meaning the secret will be checked and updated every 10 seconds. secretStoreRefs Points to the ClusterSecretStore named vault-backend, which defines where the secret will be stored. selector Identifies the secret to be pushed. In this case, it is the secret named existing-secret within the hello-world namespace. updatePolicy Specifies the policy for updating the secret in the Vault. The Replace policy will overwrite any existing secret at the target location with the new value. This configuration effectively takes a specific property (baz) from an existing secret in the hello-world namespace and pushes it to the Vault path secret/pushsecrets/testme. The secret can then be retrieved from any other namespace or node that has access to the Vault.
+`,url:"https://validatedpatterns.io/blog/2024-08-30-push-secrets/",breadcrumb:"/blog/2024-08-30-push-secrets/"},"https://validatedpatterns.io/patterns/rag-llm-gitops/":{title:"AI Generation with LLM and RAG",tags:[],content:`Document Generation Demo with LLM and RAG Introduction This deployment is based on the validated pattern framework, using GitOps for seamless provisioning of all operators and applications. It deploys a Chatbot application that harnesses the power of Large Language Models (LLMs) combined with the Retrieval-Augmented Generation (RAG) framework.
+The application uses either the EDB Postgres for Kubernetes operator (default), or Redis, to store embeddings of Red Hat product documentation, running on Red Hat OpenShift Container Platform to generate project proposals for specific Red Hat products.
+Pre-requisites Podman Red Hat Openshift cluster running in AWS. Supported regions are us-west-2 and us-east-1. GPU Node to run Hugging Face Text Generation Inference server on Red Hat OpenShift cluster. Create a fork of the rag-llm-gitops git repository. Demo Description &amp; Architecture The goal of this demo is to demonstrate a Chatbot LLM application augmented with data from Red Hat product documentation running on Red Hat OpenShift. It deploys an LLM application that connects to multiple LLM providers such as OpenAI, Hugging Face, and NVIDIA NIM. The application generates a project proposal for a Red Hat product
+Key Features LLM Application augmented with content from Red Hat product documentation. Multiple LLM providers (OpenAI, Hugging Face, NVIDIA). Vector Database, such as EDB Postgres for Kubernetes, or Redis, to store embeddings of Red Hat product documentation. Monitoring dashboard to provide key metrics such as ratings. GitOps setup to deploy e2e demo (frontend / vector database / served models). Figure 1. Overview of the validated pattern for RAG Demo with Red Hat OpenShift
+Figure 2. Logical diagram of the RAG Demo with Red Hat OpenShift.
+`,url:"https://validatedpatterns.io/patterns/rag-llm-gitops/",breadcrumb:"/patterns/rag-llm-gitops/"},"https://validatedpatterns.io/blog/2024-07-19-write-token-kubeconfig/":{title:"Writing a Kubeconfig File if You Need One",tags:[],content:`Writing a Kubeconfig File if You Need One Overview One of the questions that we occasionally get is how Patterns can work without full admin privileges. This means authenticating to a cluster without the initial kubeadmin kubeconfig file. This file is intended to be used to perform initial setup tasks as the &lsquo;kubeadmin&rsquo; or &lsquo;kube:admin&rsquo; user, and then for that user to be removed once the cluster has its permanent authentication mechanism set up (such as Oauth2 to GitHub, among many other possibilities).
+But what if a user did not have the Kubeconfig file for some reason? We did not have another mechanism for them to use the Pattern framework. This feature is intended to fill that gap, and to work towards enabling the use of Patterns when the initial Kubeconfig is not available for some reason.
+Note that in standard OpenShift installation scenarios, even for our managed offerings like ARO (managed OpenShift on Azure) and ROSA (managed OpenShift on AWS), users are given the standard starter Kubeconfig and kubeadmin password files, so if you have that Kubeconfig file, by all means use it to install Validated Patterns.
+If, however, you want to install a Validated Pattern, and you do not have the Kubeconfig file, but you do have a username/password OR you already have a valid token for that username, this feature can create a Kubeconfig file for you at ~/.kube/config (the default location for such files).
+Why This feature grew out of an interest in creating a generic mechanism to enable use of all of the Pattern tooling, and the best way to do that (at the time of writing) is to create a kubeconfig file that contains the token and cluster info. The Kubernetes Ansible module allows for logging in to a OpenShift cluster with username/password, but then does not store the resulting token. The best way to use this information in Ansible without changing all of the Ansible code or adding extra complexities (such as using module_defaults) is to craft a Kubeconfig file with the token, cluster and context information. This allows the token to be used by other tools like oc/kubectl. The Ansible Kubernetes module will also authenticate using a valid Kubeconfig file in ~/.kube/config, so this feature will create that file if it does not already exist.
+How to get started Make sure you do not currently have a ~/.kube/config file. The process will look for it and exit if one already exists. Set and export the following environment variables in your shell: K8S_AUTH_HOST: Cluster API address. Mandatory. K8S_AUTH_USERNAME: Username. Optional; defaults to kubeadmin. K8S_AUTH_PASSWORD: Password to use to obtain token. Mandatory if token is not specified. K8S_AUTH_TOKEN: An existing, valid authentication token for the cluster. If specified, the Kubeconfig file will be written with it, after validation is done that the config is valid. K8S_AUTH_VERIFY_SSL: Whether to validate SSL when communicating with the cluster. Optional; defaults to false. K8S_AUTH_SSL_CA_CERT: A filename containing the full CA chain for the cluster. Optional. Run ./pattern.sh make token-kubeconfig. This will generate ~/.kube/config if it does not already exist. This file can be used by the rest of the pattern tooling. Optionally, if you do not want to write ~/.kube/config, you can invoke the script directly with an argument to specify which file to write the kubeconfig out to. For example: ./pattern.sh common/scrtips/write-token-kubeconfig.sh ~/testfile will write the kubeconfig to ~/testfile. It will still not overwrite an existing file.
+`,url:"https://validatedpatterns.io/blog/2024-07-19-write-token-kubeconfig/",breadcrumb:"/blog/2024-07-19-write-token-kubeconfig/"},"https://validatedpatterns.io/blog/2024-07-12-in-cluster-git/":{title:"In-cluster Git Server",tags:[],content:`In-cluster Git Server Overview Starting with the patterns operator version 0.0.52 there is an initial (experimental) support for having an in-cluster git server. Once enabled, a very simple gitea server is installed and configured inside the cluster. The patterns will use the internal gitea server to pull code from. By default the Gitea server repository will sync from the upstream git repo every eight hours.
+Why One of the main reasons to have an in-cluster git server is to make it simpler to get started with patterns. It avoids the need to have a fork of the original pattern&rsquo;s git repo and the changes can be done directly in the in-cluster git repository.
+How to get started There are fundamentally two ways to set up the in-cluster gitea server.
+Via the user interface in the console by enabling the In Cluster Git Server switch inside the Git Config section: And setting the Origin Repo to the upstream git repository that needs to be imported in gitea. By creating a Pattern CR and setting the spec.gitSpec.originRepo field to the upstream git repository. In this case the spec.gitSpec.targetRepo field, which is used by the pattern to deploy the actual code, will be automatically overwritten pointing to the internal in-cluster git route. For example: apiVersion: gitops.hybrid-cloud-patterns.io/v1alpha1 kind: Pattern metadata: name: test-pattern namespace: openshift-operators spec: clusterGroupName: hub gitSpec: originRepo: https://github.com/validatedpatterns/multicloud-gitops targetRevision: main In the example above, since originRepo is not empty it will be used as the upstream git repository to clone from and that repository will be imported into gitea and targetRepo will be automatically constructed to point to the internal gitea. Configuration Once the the in-gitea cluster is enabled, its configuration will be done via a normal argo application that can be seen in the cluster-wide argo: The gitea interface can be accessed via the gitea-route inside the vp-gitea namespace or by clicking the console link on the nine box: To access the gitea admin interface a secret called gitea-admin-secret containing username and password are created inside the vp-gitea namespace.
+Repositories Once logged in with the gitea_admin user whose password is contained in the gitea-admin-secret you will see the repository that has been configured inside gitea: Clicking on the repository will show the actual code and the usual git related information (branch, tags, etc): Gitea usage To clone the gitea repository you can simply clone the repository via https:
+git -c http.sslVerify=false clone https://gitea-route-vp-gitea.apps.mcg-hub.aws.validatedpatterns.io/gitea_admin/multicloud-gitops.git In order to avoid the sslVerify=false setting you need to download your clusters CA and import it into the git config.
+You can create a token in gitea under Settings -&gt; Applications -&gt; Manage Access Tokens that repository Read and Write permissions. With this token you can clone it once with authentication and then push changes to the gitea repository:
+git -c http.sslVerify=false clone https://gitea_admin:&lt;token&gt;@gitea-route-vp-gitea.apps.mcg-hub.aws.validatedpatterns.io/gitea_admin/multicloud-gitops.git git -c http.sslVerify=false push origin mytestbranch Note: The conversion from gitea mirror to regular repository is needed unless the upstream issue gets implemented.
+`,url:"https://validatedpatterns.io/blog/2024-07-12-in-cluster-git/",breadcrumb:"/blog/2024-07-12-in-cluster-git/"},"https://validatedpatterns.io/patterns/ansible-gitops-framework/":{title:"Ansible GitOps Framework",tags:[],content:`Ansible GitOps Framework Background Ansible GitOps Framework (AGOF) is an alternative to the OpenShift-based Validated Patterns framework, designed to provide a framework for GitOps without Kubernetes. AGOF is not a pattern itself; it is a framework for installing Ansible Automation Platform (AAP), and then using that as the GitOps engine to drive other pattern work. AGOF comes with code to install VMs in AWS, if desired, or else it can work with previously provisioned VMs, or a functional AAP Controller endpoint.
+The Pattern is then expressed as an Infrastructure as Code repository, which will be loaded into AAP.
+Solution elements How to use a GitOps approach to manage non-Kubernetes workloads Red Hat Technologies Red Hat Ansible Automation Platform (formerly known as &ldquo;Ansible Tower&rdquo;) Red Hat Enterprise Linux `,url:"https://validatedpatterns.io/patterns/ansible-gitops-framework/",breadcrumb:"/patterns/ansible-gitops-framework/"},"https://validatedpatterns.io/patterns/gaudi-rag-chat-qna/":{title:"OPEA QnA chat accelerated with Intel Gaudi",tags:[],content:`About OPEA QnA chat accelerated with Intel Gaudi pattern Background Validated pattern is based on OPEA [Open Platform for Enterprise AI] example - Chat QnA. OPEA is an ecosystem orchestration framework to integrate performant GenAI technologies &amp; workflows leading to quicker GenAI adoption and business value. Another purpose of this pattern is to deploy whole infrastructure stack enabling Intel Gaudi accelerator. Accelerator is used in the AI inferencing process. Pattern makes use of GitOps approach. GitOps uses Git repositories as a single source of truth to deliver infrastructure-as-code. Submitted code will be checked by the continuous integration (CI) process, while the continuous delivery (CD) process checks and applies requirements for things like security, infrastructure-as-code, or any other boundaries set for the application framework. All changes to code are tracked, making updates easy while also providing version control should a rollback be needed.
+Components Kernel Module Management operator (KMM) and HabanaAI operator are responsible for providing Gaudi accelerators within the OpenShift cluster, including drivers and monitoring metrics
+Node Feature Discovery operator labels all cluster nodes with Gaudi resources available
+AI Chat microservices:
+Embedding service - is designed to efficiently convert textual strings into vectorized embeddings, facilitating seamless integration into various machine learning and data processing workflows.
+Vector Database - stores embedded vectors.
+Retriever service - is a highly efficient search service designed for handling and retrieving embedding vectors.
+Reranking service - when provided with a query and a collection of documents, reranking swiftly indexes the documents based on their semantic relevance to the query, arranging them from most to least pertinent.
+Data preparation service - aims to preprocess the data from various sources (either structured or unstructured data) to text data, and convert the text data to embedding vectors then store them in the database.
+LLM service - processes input consisting of a query string and associated reranked documents. It constructs a prompt based on the query and documents, which is then used to perform inference with a large language model.
+Backend service
+Frontend service
+TGI (Text Generation Inference) using Red Hat OpenShift AI
+About the solution Following solution is based on OPEA [Open Platform for Enterprise AI] example - Chat QnA, but it is additionally wrapped in the Validated Patterns framework. It means that it uses GitOps approach, where every defined component is a microservice and its status can be easily tracked using ArgoCD dashboard. Moreover this approach makes use of OpenShift Data Foundation solution to store all data, like machine learning model on the cluster. AI model in this case is Llama-2-70b-chat-hf. High-level structure of Validated Pattern is shown below:
+Figure 1. Overview of the solution OPEA QnA Chat stack is composed out of Embedding service, Vector Database, Retriever, Reranking service, data preparation service, LLM server and back-/frontend applications.
+Gaudi enablement stack consists of Kernel Module Management and HabanaAI operators.
+Additionally, in this Validated Pattern OpenShift Data Foundation is used to provide an S3-like storage through Ceph RGW, and Image Registry is used to store all built images and Hashicorp Vault to safely keep HuggingFace User token.
+Node Feature Discovery labels Gaudi 2 nodes so the workload can be placed on the right node and benefit from the acceleration.
+About the technology The following technologies are used in this solution:
+Red Hat OpenShift Platform An enterprise-ready Kubernetes container platform built for an open hybrid cloud strategy. It provides a consistent application platform to manage hybrid cloud, public cloud, and edge deployments. It delivers a complete application platform for both traditional and cloud-native applications, allowing them to run anywhere. OpenShift has a pre-configured, pre-installed, and self-updating monitoring stack that provides monitoring for core platform components. It also enables the use of external secret management systems, for example, HashiCorp Vault in this case, to securely add secrets into the OpenShift platform.
+Red Hat OpenShift GitOps A declarative application continuous delivery tool for Kubernetes based on the ArgoCD project. Application definitions, configurations, and environments are declarative and version controlled in Git. It can automatically push the desired application state into a cluster, quickly find out if the application state is in sync with the desired state, and manage applications in multi-cluster environments.
+Red Hat Ansible Automation Platform Provides an enterprise framework for building and operating IT automation at scale across hybrid clouds including edge deployments. It enables users across an organization to create, share, and manage automation, from development and operations to security and network teams.
+Red Hat OpenShift Data Foundation It is software-defined storage for containers. Red Hat OpenShift Data Foundation helps teams develop and deploy applications quickly and efficiently across clouds.
+Red Hat OpenShift AI Red Hat® OpenShift® AI is a flexible, scalable artificial intelligence (AI) and machine learning (ML) platform that enables enterprises to create and deliver AI-enabled applications at scale across hybrid cloud environments.
+Red Hat OpenShift Serverless Red Hat® OpenShift® Serverless simplifies the development of hybrid cloud applications by eliminating the complexities associated with Kubernetes and the infrastructure applications are developed and deployed on. Developers will be able to focus on coding applications instead of managing intricate infrastructure details.
+Red Hat OpenShift Service Mesh Red Hat® OpenShift® Service Mesh provides a uniform way to connect, manage, and observe microservices-based applications. It provides behavioral insight into—and control of—the networked microservices in your service mesh.
+Hashicorp Vault Provides a secure centralized store for dynamic infrastructure and applications across clusters, including over low-trust networks between clouds and data centers.
+OPEA OPEA is an ecosystem orchestration framework to integrate performant GenAI technologies &amp; workflows leading to quicker GenAI adoption and business value.
+Next steps Deploy the pattern.
+`,url:"https://validatedpatterns.io/patterns/gaudi-rag-chat-qna/",breadcrumb:"/patterns/gaudi-rag-chat-qna/"},"https://validatedpatterns.io/patterns/openshift-ai/":{title:"OpenShift AI",tags:[],content:` About the Red Hat OpenShift AI pattern Use case Use a GitOps approach to manage hybrid and multi-cloud deployments across both public and private clouds.
+Enable cross-cluster governance and application lifecycle management.
+Securely manage secrets across the deployment.
+Based on the requirements of a specific implementation, certain details might differ. However, all validated patterns that are based on a portfolio architecture, generalize one or more successful deployments of a use case.
+Background The {rhoai-pattern} deployed using OpenShift GitOps and is comprised of Red Hat OpenShift AI and OpenShift Pipelines. This pattern deploys the minimum capabilities necessary for consumers to quickly start implementing their MLOps or AI workloads in an automated way.
+Organizations are aiming to develop, deploy, and operate applications on an open hybrid cloud in a stable, simple, and secure way. This hybrid strategy includes multi-cloud deployments where workloads might be running on multiple clusters and on multiple clouds, private or public. This strategy requires an infrastructure-as-code approach: GitOps. GitOps uses Git repositories as a single source of truth to deliver infrastructure-as-code. Submitted code will be checked by the continuous integration (CI) process, while the continuous delivery (CD) process checks and applies requirements for things like security, infrastructure-as-code, or any other boundaries set for the application framework. All changes to code are tracked, making updates easy while also providing version control should a rollback be needed.
+About the solution This architecture covers a single cluster for all DevOps and GitOps functionality. However, one could extend this architecture to meet hybrid or multicloud demand using a GitOps approach
+Benefits of Hybrid Multicloud management with GitOps:
+Unify management across cloud environments.
+Dynamic infrastructure security.
+Infrastructural continuous delivery best practices.
+In the following figure, logically, this solution can be viewed as being composed of an automation component, unified management including secrets management, and the clusters under management, all running on top of a user-chosen mixture of on-premise data centers and public clouds.
+Figure 1. Logical diagram of hybrid multi-cloud management with GitOps About the technology The following technologies are used in this solution:
+Red Hat OpenShift Platform An enterprise-ready Kubernetes container platform built for an open hybrid cloud strategy. It provides a consistent application platform to manage hybrid cloud, public cloud, and edge deployments. It delivers a complete application platform for both traditional and cloud-native applications, allowing them to run anywhere. OpenShift has a pre-configured, pre-installed, and self-updating monitoring stack that provides monitoring for core platform components. It also enables the use of external secret management systems, for example, HashiCorp Vault in this case, to securely add secrets into the OpenShift platform.
+Red Hat OpenShift GitOps A declarative application continuous delivery tool for Kubernetes based on the ArgoCD project. Application definitions, configurations, and environments are declarative and version controlled in Git. It can automatically push the desired application state into a cluster, quickly find out if the application state is in sync with the desired state, and manage applications in multi-cluster environments.
+Red Hat Advanced Cluster Management for Kubernetes Controls clusters and applications from a single console, with built-in security policies. Extends the value of Red Hat OpenShift by deploying apps, managing multiple clusters, and enforcing policies across multiple clusters at scale.
+Red Hat OpenShift AI A flexible, scalable MLOps platform with tools to build, deploy, and manage AI-enabled applications. Built using open source technologies, it provides trusted, operationally consistent capabilities for teams to experiment serve models, and deliver innovative apps.
+Red Hat OpenShift Pipelines Red Hat OpenShift Pipelines is a cloud-native, continuous integratino and continuous delivery (CI/CD) solution based on Kubernetes resources. It uses Tekton building blocks to automate deployments across multiple platforms by abstracting away the underlying implementation details. Tekton introduces a number of standard custom resource definitions (CRDs) for defining CI/CD pipelines that are portable across Kubernetes distributions.
+Red Hat Ansible Automation Platform Provides an enterprise framework for building and operating IT automation at scale across hybrid clouds including edge deployments. It enables users across an organization to create, share, and manage automation, from development and operations to security and network teams.
+Hashicorp Vault Provides a secure centralized store for dynamic infrastructure and applications across clusters, including over low-trust networks between clouds and data centers.
+This solution also uses a variety of observability tools including the Prometheus monitoring and Grafana dashboard that are integrated with OpenShift as well as components of the Observatorium meta-project which includes Thanos and the Loki API.
+Overview of the architectures The following figure provides a high level architectural overview of the OpenShift AI pattern.
+Figure 2. Overview schematic diagram of the complete solution Subsequent schematic diagrams provide details on:
+Hybrid multi-cloud GitOps
+Dynamic security management
+Hybrid Multicloud GitOps The following figure provides a schematic diagram showing remaining activities associated with setting up the management hub and clusters using Red Hat Advanced Cluster Management.
+Figure 3. Schematic diagram of hybrid multi-cloud management with GitOps Manifest and configuration are set as code template in the form of a Kustomization YAML file. The file describes the desired end state of the managed cluster. When complete, the Kustomization YAML file is pushed into the source control management repository with a version assigned to each update.
+OpenShift GitOps monitors the repository and detects changes in the repository.
+OpenShift GitOps creates and updates the manifest by creating Kubernetes objects on top of Red Hat Advanced Cluster Management.
+Red Hat Advanced Cluster Management provisions, updates, or deletes managed clusters and configuration according to the manifest. In the manifest, you can configure what cloud provider the cluster will be on, the name of the cluster, infrastructure node details and worker node. Governance policy can also be applied as well as provision an agent in the cluster as the bridge between the control center and the managed cluster.
+OpenShift GitOps continuously monitors the code repository and the status of the clusters reported back to Red Hat Advanced Cluster Management. Any configuration drift or in case of any failure, OpenShift GitOps will automatically try to remediate by applying the manifest or by displaying alerts for manual intervention.
+Dynamic security management The following figure provides a schematic diagram showing how secrets are handled in this solution.
+Figure 4. Schematic showing the setup and use of external secrets management During setup, the token to securely access HashiCorp Vault is stored in Ansible Vault. It is encrypted to protect sensitive content.
+Red Hat Advanced Cluster Management for Kubernetes acquires the token from Ansible Vault during install and distributes it among the clusters. As a result, you have centralized control over the managed clusters through RHACM.
+To allow the cluster access to the external vault, you must set up the external secret management with Helm in this study. OpenShift Gitops is used to deploy the external secret object to a managed cluster.
+External secret management fetches secrets from HashiCorp Vault by using the token that was generated in step 2 and constantly monitors for updates.
+Secrets are created in each namespace, where applications can use them.
+Next steps Deploy the Pattern using Helm.
+`,url:"https://validatedpatterns.io/patterns/openshift-ai/",breadcrumb:"/patterns/openshift-ai/"},"https://validatedpatterns.io/patterns/multicloud-gitops-amx-rhoai/":{title:"Intel AMX accelerated Multicloud GitOps with Openshift AI",tags:[],content:` About the Intel AMX accelerated Multicloud GitOps pattern with Openshift AI Use case Use a GitOps approach to manage hybrid and multi-cloud deployments across both public and private clouds.
+Enable cross-cluster governance and application lifecycle management.
+Accelerate AI operations and improve computational performance by using Intel Advanced Matrix Extensions together with Openshift AI operator.
+Securely manage secrets across the deployment.
+Based on the requirements of a specific implementation, certain details might differ. However, all validated patterns that are based on a portfolio architecture, generalize one or more successful deployments of a use case.
+Background Organizations are aiming to develop, deploy, and operate applications on an open hybrid cloud in a stable, simple, and secure way. This hybrid strategy includes multi-cloud deployments where workloads might be running on multiple clusters and on multiple clouds, private or public. This strategy requires an infrastructure-as-code approach: GitOps. GitOps uses Git repositories as a single source of truth to deliver infrastructure-as-code. Submitted code checks the continuous integration (CI) process, while the continuous delivery (CD) process checks and applies requirements for things like security, infrastructure-as-code, or any other boundaries set for the application framework. All changes to code are tracked, making updates easy while also providing version control should a rollback be needed. Moreover, organizations are looking for solutions that increase efficiency and at the same time reduce costs, what is possible using 5th Generation Intel Xeon Scalable Processors with a new build-in accelerator - Intel Advanced Matrix Extensions.
+About the solution This architecture covers hybrid and multi-cloud management with GitOps as shown in following figure. At a high level this requires a management hub, for DevOps and GitOps, and infrastructure that extends to one or more managed clusters running on private or public clouds. The automated infrastructure-as-code approach can manage the versioning of components and deploy according to the infrastructure-as-code configuration.
+Benefits of Hybrid Multicloud management with GitOps:
+Unify management across cloud environments.
+Dynamic infrastructure security.
+Infrastructural continuous delivery best practices.
+Figure 1. Overview of the solution including the business drivers, management hub, and the clusters under management About the technology The following technologies are used in this solution:
+Red Hat OpenShift Platform An enterprise-ready Kubernetes container platform built for an open hybrid cloud strategy. It provides a consistent application platform to manage hybrid cloud, public cloud, and edge deployments. It delivers a complete application platform for both traditional and cloud-native applications, allowing them to run anywhere. OpenShift has a pre-configured, pre-installed, and self-updating monitoring stack that provides monitoring for core platform components. It also enables the use of external secret management systems, for example, HashiCorp Vault in this case, to securely add secrets into the OpenShift platform.
+Red Hat OpenShift GitOps A declarative application continuous delivery tool for Kubernetes based on the ArgoCD project. Application definitions, configurations, and environments are declarative and version controlled in Git. It can automatically push the desired application state into a cluster, quickly find out if the application state is in sync with the desired state, and manage applications in multi-cluster environments.
+Red Hat Advanced Cluster Management for Kubernetes Controls clusters and applications from a single console, with built-in security policies. Extends the value of Red Hat OpenShift by deploying apps, managing multiple clusters, and enforcing policies across multiple clusters at scale.
+Red Hat Ansible Automation Platform Provides an enterprise framework for building and operating IT automation at scale across hybrid clouds including edge deployments. It enables users across an organization to create, share, and manage automation, from development and operations to security and network teams.
+Node Feature Discovery Operator Manages the detection of hardware features and configuration in an OpenShift Container Platform cluster by labeling the nodes with hardware-specific information. NFD labels the host with node-specific attributes, such as PCI cards, kernel, operating system version, and so on.
+Red Hat Openshift AI A flexible, scalable MLOps platform with tools to build, deploy, and manage AI-enabled applications. OpenShift AI (previously called Red Hat OpenShift Data Science) supports the full lifecycle of AI/ML experiments and models, on-premise and in the public cloud.
+OpenVINO Toolkit Operator The Operator includes OpenVINO™ Notebooks for development of AI optimized workloads and OpenVINO™ Model Server for deployment that enables AI inference execution at scale, and exposes AI models via gRPC and REST API interfaces.
+Intel® Advanced Matrix Extensions A new built-in accelerator that improves the performance of deep-learning training and inference on the CPU and is ideal for workloads like natural-language processing, recommendation systems and image recognition.
+Hashicorp Vault Provides a secure centralized store for dynamic infrastructure and applications across clusters, including over low-trust networks between clouds and data centers.
+This solution also uses a variety of observability tools including the Prometheus monitoring and Grafana dashboard that are integrated with OpenShift as well as components of the Observatorium meta-project which includes Thanos and the Loki API.
+Intel AMX accelerated Multicloud GitOps pattern with Openshift AI The basic Multicloud GitOps pattern has been extended to highlight the 5th Generation Intel Xeon Scalable Processors capabilities, offering developers a streamlined pathway to accelerate their workloads through the integration of cutting-edge Intel AMX, providing efficiency and performance optimization in AI workloads.
+The basic pattern has been extended with two components: Openshift AI and OpenVINO Toolkit Operator.
+Openshift AI, serves as a robust AI/ML platform for the creation of AI-driven applications and provides a collaborative environment for data scientists and developers that helps to move easily from experiment to production. It offers Jupyter application with selection of notebook servers, equipped with pre-configured environments and necessary support and optimizations (such as CUDA, PyTorch, Tensorflow, HabanaAI, etc.).
+OpenVINO Toolkit Operator manages OpenVINO components within Openshift environment. First one, OpenVINO™ Model Server (OVMS) is a scalable, high-performance solution for serving machine learning models optimized for Intel® architectures. The other component, that was used in the proposed pattern is Notebook resource. This element integrates Jupyter from OpenShift AI with a container image that includes developer tools from the OpenVINO toolkit. It also enables selecting a defined image OpenVINO™ Toolkit from the Jupyter Spawner choice list.
+BERT-Large model is used as an example of AI workload using Intel AMX in the pattern. The BERT-Large inference is running in the Jupyter Notebook that uses OpenVINO optimizations.
+As a side note, BERT_Large is a wide known model used by various enterprise Natural Language Processing workloads. Intel has demonstrated, that 5th Generation Intel Xeon Scalable Processors perform up to 1.49 times better in NLP flows on Red Hat OpenShift vs. prior generation of processors- read more: Level Up Your NLP applications on Red Hat OpenShift and 5th Gen
+Next steps Deploy the management hub using Helm.
+Add a managed cluster to deploy the managed cluster piece using ACM.
+`,url:"https://validatedpatterns.io/patterns/multicloud-gitops-amx-rhoai/",breadcrumb:"/patterns/multicloud-gitops-amx-rhoai/"},"https://validatedpatterns.io/patterns/multicloud-gitops-sgx-hello-world/":{title:"Intel SGX protected application in Multicloud GitOps",tags:[],content:` About the Intel SGX protected application in Multicloud GitOps pattern Use case Use a GitOps approach to manage hybrid and multi-cloud deployments across both public and private clouds.
+Enable cross-cluster governance and application lifecycle management.
+Securely manage secrets across the deployment.
+Effectively protect data in use with Intel Software Guard Extensions.
+Based on the requirements of a specific implementation, certain details might differ. However, all validated patterns that are based on a portfolio architecture, generalize one or more successful deployments of a use case.
+Background Organizations are aiming to develop, deploy, and operate applications on an open hybrid cloud in a stable, simple, and secure way. This hybrid strategy includes multi-cloud deployments where workloads might be running on multiple clusters and on multiple clouds, private or public. This strategy requires an infrastructure-as-code approach: GitOps. GitOps uses Git repositories as a single source of truth to deliver infrastructure-as-code. Submitted code checks the continuous integration (CI) process, while the continuous delivery (CD) process checks and applies requirements for things like security, infrastructure-as-code, or any other boundaries set for the application framework. All changes to code are tracked, making updates easy while also providing version control should a rollback be needed. Moreover, organizations are looking for solutions that are secure for AI, ML, data processing etc. It is the case especially for cloud computing, which uses heavily multi-tenancy and multiple processes runs on single bare-metal machine and they do not know who might be their neighbors and what are their intentions. Memory encryption technologies can protect well the data and separate application from other ones run on the same machine - it is possible using 5th Generation Intel Xeon Scalable Processors with Intel Software Guard Extensions.
+About the solution This architecture covers hybrid and multi-cloud management with GitOps as shown in following figure. At a high level this requires a management hub, for DevOps and GitOps, and infrastructure that extends to one or more managed clusters running on private or public clouds. The automated infrastructure-as-code approach can manage the versioning of components and deploy according to the infrastructure-as-code configuration.
+Benefits of Hybrid Multicloud management with GitOps:
+Unify management across cloud environments.
+Dynamic infrastructure security.
+Infrastructural continuous delivery best practices.
+Figure 1. Overview of the solution including the business drivers, management hub, and the clusters under management In the following figure, logically, this solution can be viewed as being composed of an automation component, unified management including secrets management, and the clusters under management, all running on top of a user-chosen mixture of on-premise data centers and public clouds.
+Figure 2. Logical diagram of Intel SGX accelerated hybrid multi-cloud management with GitOps About the technology The following technologies are used in this solution:
+Red Hat OpenShift Platform An enterprise-ready Kubernetes container platform built for an open hybrid cloud strategy. It provides a consistent application platform to manage hybrid cloud, public cloud, and edge deployments. It delivers a complete application platform for both traditional and cloud-native applications, allowing them to run anywhere. OpenShift has a pre-configured, pre-installed, and self-updating monitoring stack that provides monitoring for core platform components. It also enables the use of external secret management systems, for example, HashiCorp Vault in this case, to securely add secrets into the OpenShift platform.
+Red Hat OpenShift GitOps A declarative application continuous delivery tool for Kubernetes based on the ArgoCD project. Application definitions, configurations, and environments are declarative and version controlled in Git. It can automatically push the desired application state into a cluster, quickly find out if the application state is in sync with the desired state, and manage applications in multi-cluster environments.
+Red Hat Advanced Cluster Management for Kubernetes Controls clusters and applications from a single console, with built-in security policies. Extends the value of Red Hat OpenShift by deploying apps, managing multiple clusters, and enforcing policies across multiple clusters at scale.
+Red Hat Ansible Automation Platform Provides an enterprise framework for building and operating IT automation at scale across hybrid clouds including edge deployments. It enables users across an organization to create, share, and manage automation, from development and operations to security and network teams.
+Node Feature Discovery Operator Manages the detection of hardware features and configuration in an OpenShift Container Platform cluster by labeling the nodes with hardware-specific information. NFD labels the host with node-specific attributes, such as PCI cards, kernel, operating system version, and so on.
+Intel® Device Plugins Operator Is a collection of device plugins advertising Intel specific hardware resources to the kubelet. Currently the operator has basic support for the QAT, GPU, FPGA, SGX, DSA, IAA device plugins: it validates container image references and extends reported statuses.
+Intel® Software Guard Extensions Helps protect data in use via unique application isolation technology. Protect selected code and data from modification using hardened enclaves with Intel SGX.
+Gramine Shielded Containers Transforms a Docker image into a new image which includes the Gramine Library OS, manifest files, Intel SGX related information, and executes the application inside an Intel SGX enclave using the Gramine Library OS.
+Hashicorp Vault Provides a secure centralized store for dynamic infrastructure and applications across clusters, including over low-trust networks between clouds and data centers.
+This solution also uses a variety of observability tools including the Prometheus monitoring and Grafana dashboard that are integrated with OpenShift as well as components of the Observatorium meta-project which includes Thanos and the Loki API.
+Overview of the architectures The following figure provides a schematic diagram overview of the complete solution including both components and data flows.
+Figure 3. Overview schematic diagram of the complete solution Subsequent schematic diagrams provide details on:
+Bootstrapping the management hub (Figure 4)
+Hybrid multi-cloud GitOps (Figure 5)
+Dynamic security management (Figure 6)
+Bootstrapping the management hub The following figure provides a schematic diagram showing the setup of the management hub using Ansible playbooks.
+Figure 4. Schematic diagram of bootstrapping the management hub Set up the OpenShift Container Platform that hosts the Management Hub. The OpenShift installation program provides flexible ways to install OpenShift. An Ansible playbook starts the installation with necessary configurations.
+Ansible playbooks deploy and configure Red Hat Advanced Cluster Management for Kubernetes and, later, other supporting components such as external secrets management, on top of the provisioned OpenShift cluster.
+Another Ansible playbook installs HashiCorp Vault, a Red Hat partner product chosen for this solution that can be used to manage secrets for OpenShift clusters.
+An Ansible playbook configures and installs the Openshift GitOps operator on the hub cluster. This deploys the Openshift GitOps instance to enable continuous delivery.
+Hybrid Multicloud GitOps The following figure provides a schematic diagram showing remaining activities associated with setting up the management hub and clusters using Red Hat Advanced Cluster Management.
+Figure 5. Schematic diagram of hybrid multi-cloud management with GitOps Manifest and configuration are set as code template in the form of a Kustomization YAML file. The file describes the desired end state of the managed cluster. When complete, the Kustomization YAML file is pushed into the source control management repository with a version assigned to each update.
+OpenShift GitOps monitors the repository and detects changes in the repository.
+OpenShift GitOps creates and updates the manifest by creating Kubernetes objects on top of Red Hat Advanced Cluster Management.
+Red Hat Advanced Cluster Management provisions, updates, or deletes managed clusters and configuration according to the manifest. In the manifest, you can configure what cloud provider the cluster will be on, the name of the cluster, infrastructure node details and worker node. Governance policy can also be applied as well as provision an agent in the cluster as the bridge between the control center and the managed cluster.
+OpenShift GitOps continuously monitors the code repository and the status of the clusters reported back to Red Hat Advanced Cluster Management. Any configuration drift or in case of any failure, OpenShift GitOps will automatically try to remediate by applying the manifest or by displaying alerts for manual intervention.
+Dynamic security management The following figure provides a schematic diagram showing how secrets are handled in this solution.
+Figure 6. Schematic showing the setup and use of external secrets management During setup, the token to securely access HashiCorp Vault is stored in Ansible Vault. It is encrypted to protect sensitive content.
+Red Hat Advanced Cluster Management for Kubernetes acquires the token from Ansible Vault during install and distributes it among the clusters. As a result, you have centralized control over the managed clusters through RHACM.
+To allow the cluster access to the external vault, you must set up the external secret management with Helm in this study. OpenShift Gitops is used to deploy the external secret object to a managed cluster.
+External secret management fetches secrets from HashiCorp Vault by using the token that was generated in step 2 and constantly monitors for updates.
+Secrets are created in each namespace, where applications can use them.
+Additional resources View and download all of the diagrams above from the Red Hat Portfolio Architecture open source tooling site.
+Intel SGX protected application in Multicloud GitOps pattern The basic Multicloud GitOps pattern has been extended to highlight the 5th Generation Intel Xeon Scalable Processors capabilities, offering developers Intel SGX as a streamlined pathway to protect data in use against threats with isolation, encryption, and attestation while also allowing users to maintain control and use their data.
+The application which has been added to the basic pattern is named hello-world-sgx. It is a simple Python application that runs securely inside the SGX enclave. SGX enclave is an encrypted memory, which prevents unauthorized access from other containers running on the same host or even some host’s processes.
+The sample application uses image converted with Gramine Shielded Containers (GSC) tools to include Intel SGX related information and execute the application inside an Intel SGX enclave using the Gramine Library OS. It’s an easy way to convert the application into its secure version.
+Since the hello-world-sgx application must be running on the node with CPU supporting Intel SGX, Node Feature Discovery Operator (NFD) and Intel Device Plugins Operator (IDP) are deployed as a part of this pattern.
+NFD manages the detection of hardware features and configuration in an OpenShift Container Platform cluster. It labels the nodes with hardware-specific information. It is a requirement for IDP installation. IDP provides resources which are the user interface to claim and consume the hardware feature by user pods and also advertises Intel-specific hardware resources to the kubelet.
+In the logs of hello-world-sgx pod, there is an information that &#34;Gramine is starting&#34; and it executes the application by printing &#34;HelloWorld!&#34;.
+This pattern demonstrates basic capabilities of running docker applications inside SGX enclaves. Based on this pattern other applications can be secured with Intel SGX and Gramine Shielded Containers in a similar way as presented here.
+Figure 7. Logs from hello-world-sgx pod Next steps Deploy the management hub using Helm.
+Add a managed cluster to deploy the managed cluster piece using ACM.
+`,url:"https://validatedpatterns.io/patterns/multicloud-gitops-sgx-hello-world/",breadcrumb:"/patterns/multicloud-gitops-sgx-hello-world/"},"https://validatedpatterns.io/patterns/multicloud-gitops-sgx/":{title:"Intel SGX protected Vault for Multicloud GitOps",tags:[],content:` About the Intel SGX protected Vault for Multicloud GitOps pattern Use case Use a GitOps approach to manage hybrid and multi-cloud deployments across both public and private clouds.
+Enable cross-cluster governance and application lifecycle management.
+Protect a key component by using Intel Security Guard Extensions.
+Securely manage secrets across the deployment.
+Based on the requirements of a specific implementation, certain details might differ. However, all validated patterns that are based on a portfolio architecture, generalize one or more successful deployments of a use case.
+Background Organizations are aiming to develop, deploy, and operate applications on an open hybrid cloud in a stable, simple, and secure way. This hybrid strategy includes multi-cloud deployments where workloads might be running on multiple clusters and on multiple clouds, private or public. This strategy requires an infrastructure-as-code approach: GitOps. GitOps uses Git repositories as a single source of truth to deliver infrastructure-as-code. Submitted code checks the continuous integration (CI) process, while the continuous delivery (CD) process checks and applies requirements for things like security, infrastructure-as-code, or any other boundaries set for the application framework. All changes to code are tracked, making updates easy while also providing version control should a rollback be needed. Moreover, organizations are looking for solutions that increase protection, which is possible using 5th Generation Intel Xeon Scalable Processors with running application code in a protected way using Intel Security Guard Extensions.
+About the solution This architecture covers hybrid and multi-cloud management with GitOps as shown in following figure. At a high level this requires a management hub, for DevOps and GitOps, and infrastructure that extends to one or more managed clusters running on private or public clouds. The automated infrastructure-as-code approach can manage the versioning of components and deploy according to the infrastructure-as-code configuration.
+Benefits of Hybrid Multicloud management with GitOps:
+Unify management across cloud environments.
+Dynamic infrastructure security.
+Infrastructural continuous delivery best practices.
+Figure 1. Overview of the solution including the business drivers, management hub, and the clusters under management In the following figure, logically, this solution can be viewed as being composed of an automation component, unified management including secrets management, and the clusters under management, all running on top of a user-chosen mixture of on-premise data centers and public clouds.
+Figure 2. Logical diagram of Intel SGX protected hybrid multi-cloud management with GitOps About the technology The following technologies are used in this solution:
+Red Hat OpenShift Platform An enterprise-ready Kubernetes container platform built for an open hybrid cloud strategy. It provides a consistent application platform to manage hybrid cloud, public cloud, and edge deployments. It delivers a complete application platform for both traditional and cloud-native applications, allowing them to run anywhere. OpenShift has a pre-configured, pre-installed, and self-updating monitoring stack that provides monitoring for core platform components. It also enables the use of external secret management systems, for example, HashiCorp Vault in this case, to add secrets in a protected way into the OpenShift platform.
+Red Hat OpenShift GitOps A declarative application continuous delivery tool for Kubernetes based on the ArgoCD project. Application definitions, configurations, and environments are declarative and version controlled in Git. It can automatically push the desired application state into a cluster, quickly find out if the application state is in sync with the desired state, and manage applications in multi-cluster environments.
+Red Hat Advanced Cluster Management for Kubernetes Controls clusters and applications from a single console, with built-in security policies. Extends the value of Red Hat OpenShift by deploying apps, managing multiple clusters, and enforcing policies across multiple clusters at scale.
+Red Hat Ansible Automation Platform Provides an enterprise framework for building and operating IT automation at scale across hybrid clouds including edge deployments. It enables users across an organization to create, share, and manage automation, from development and operations to security and network teams.
+Node Feature Discovery Operator Manages the detection of hardware features and configuration in an OpenShift Container Platform cluster by labeling the nodes with hardware-specific information. NFD labels the host with node-specific attributes, such as PCI cards, kernel, operating system version, and so on.
+Intel® Device Plugins Operator Is a collection of device plugins advertising Intel-specific hardware resources to the kubelet. Currently, the operator has basic support for the QAT, GPU, FPGA, SGX, DSA, IAA device plugins: it validates container image references and extends reported statuses.
+Intel® Software Guard Extensions Helps protect data in use via unique application isolation technology. Protect selected code and data from modification using hardened enclaves with Intel SGX.
+Gramine Shielded Containers Transforms a Docker image into a new image which includes the Gramine Library OS, manifest files, Intel SGX-related information, and executes the application inside an Intel SGX enclave using the Gramine Library OS.
+Hashicorp Vault Provides a protected centralized store for dynamic infrastructure and applications across clusters, including over low-trust networks between clouds and data centers.
+This solution also uses a variety of observability tools including the Prometheus monitoring and Grafana dashboard that are integrated with OpenShift as well as components of the Observatorium meta-project which includes Thanos and the Loki API.
+Overview of the architectures The following figure provides a schematic diagram overview of the complete solution including both components and data flows.
+Figure 3. Overview schematic diagram of the complete solution Subsequent schematic diagrams provide details on:
+Bootstrapping the management hub (Figure 4)
+Hybrid multi-cloud GitOps (Figure 5)
+Dynamic security management (Figure 6)
+Bootstrapping the management hub The following figure provides a schematic diagram showing the setup of the management hub using Ansible playbooks.
+Figure 4. Schematic diagram of bootstrapping the management hub Set up the OpenShift Container Platform that hosts the Management Hub. The OpenShift installation program provides flexible ways to install OpenShift. An Ansible playbook starts the installation with necessary configurations.
+Ansible playbooks deploy and configure Red Hat Advanced Cluster Management for Kubernetes and, later, other supporting components such as external secrets management, on top of the provisioned OpenShift cluster.
+Another Ansible playbook installs HashiCorp Vault, a Red Hat partner product chosen for this solution that can be used to manage secrets for OpenShift clusters.
+An Ansible playbook configures and installs the Openshift GitOps operator on the hub cluster. This deploys the Openshift GitOps instance to enable continuous delivery.
+Hybrid Multicloud GitOps The following figure provides a schematic diagram showing remaining activities associated with setting up the management hub and clusters using Red Hat Advanced Cluster Management.
+Figure 5. Schematic diagram of hybrid multi-cloud management with GitOps Manifest and configuration are set as code template in the form of a Kustomization YAML file. The file describes the desired end state of the managed cluster. When complete, the Kustomization YAML file is pushed into the source control management repository with a version assigned to each update.
+OpenShift GitOps monitors the repository and detects changes in the repository.
+OpenShift GitOps creates and updates the manifest by creating Kubernetes objects on top of Red Hat Advanced Cluster Management.
+Red Hat Advanced Cluster Management provisions, updates, or deletes managed clusters and configuration according to the manifest. In the manifest, you can configure what cloud provider the cluster will be on, the name of the cluster, infrastructure node details and worker node. Governance policy can also be applied as well as provision an agent in the cluster as the bridge between the control center and the managed cluster.
+OpenShift GitOps continuously monitors the code repository and the status of the clusters reported back to Red Hat Advanced Cluster Management. Any configuration drift or in case of any failure, OpenShift GitOps will automatically try to remediate by applying the manifest or by displaying alerts for manual intervention.
+Dynamic security management The following figure provides a schematic diagram showing how secrets are handled in this solution.
+Figure 6. Schematic showing the setup and use of external secrets management During setup, the token to access HashiCorp Vault in a protected way is stored in Ansible Vault. It is encrypted to protect sensitive content.
+Red Hat Advanced Cluster Management for Kubernetes acquires the token from Ansible Vault during install and distributes it among the clusters. As a result, you have centralized control over the managed clusters through RHACM.
+To allow the cluster access to the external vault, you must set up the external secret management with Helm in this study. OpenShift Gitops is used to deploy the external secret object to a managed cluster.
+External secret management fetches secrets from HashiCorp Vault by using the token that was generated in step 2 and constantly monitors for updates.
+Secrets are created in each namespace, where applications can use them.
+Additional resources View and download all of the diagrams above from the Red Hat Portfolio Architecture open source tooling site.
+Intel SGX protected Vault for Multicloud GitOps pattern The basic Multicloud GitOps pattern has been extended to highlight the 5th Generation Intel Xeon Scalable Processors capabilities, by running one of the components in Intel SGX memory enclave. This cutting-edge technology allows them to run applications in a way that increases security and prevents malicious actors from accessing the RAM of running applications. Also, it is very important not only on-premise but especially when running in the cloud environment.
+The effort to start using Intel Security Guard Extensions is minimal as no changes to the code of the existing application are required. Tools like Gramine Shielded Containers allow a lift-and-shift approach and convert existing container images to their protected version which runs existing applications in an encrypted enclave.
+The basic pattern has been improved by protecting the Vault component, which is a crucial component of MultiCloud GitOps pattern. The Vault component is run in a trusted execution environment.
+Since protected Vault using Intel SGX must be running on the node with CPU supporting Intel SGX, Node Feature Discovery Operator (NFD) and Intel Device Plugins Operator (IDP) are deployed as a part of this pattern.
+NFD manages the detection of hardware features and configuration in an OpenShift Container Platform cluster. It labels the nodes with hardware-specific information. It is the requirement for IDP installation. IDP advertises Intel-specific hardware resources to the cluster.
+In the logs of vault-0 pod there is information that &#34;Gramine is starting&#34; and Vault is launched in encrypted RAM.
+Vault was chosen because it is a common component of this pattern and it might be used in many places, so protecting it introduces even more benefits.
+Sample logs from vault-0 pod:
+Gramine is starting. Parsing TOML manifest file, this may take some time... ----------------------------------------------------------------------------------------------------------------------- Gramine detected the following insecure configurations: - sgx.allowed_files = [ ... ] (some files are passed through from untrusted host without verification) Gramine will continue application execution, but this configuration must not be used in production! ----------------------------------------------------------------------------------------------------------------------- Emulating a raw syscall instruction. This degrades performance, consider patching your application to use Gramine syscall API. ==&gt; Vault server configuration: Administrative Namespace: Api Address: http://10.128.1.233:8200 Cgo: disabled Cluster Address: https://vault-0.vault-internal:8201 Environment Variables: GODEBUG, HOME, HOSTNAME, HOST_IP, LD_LIBRARY_PATH, NAME, PATH, POD_IP, SKIP_CHOWN, SKIP_SETCAP, VAULT_ADDR, VAULT_API_ADDR, VAULT_CACERT, VAULT_CLUSTER_ADDR, VAULT_K8S_NAMESPACE, VAULT_K8 S_POD_NAME, VERSION, container Go Version: go1.21.4 Listener 1: tcp (addr: &#34;[::]:8200&#34;, cluster address: &#34;[::]:8201&#34;, max_request_duration: &#34;1m30s&#34;, max_request_size: &#34;33554432&#34;, tls: &#34;enabled&#34;) Log Level: Mlock: supported: true, enabled: false Recovery Mode: false Storage: file Version: Vault v1.15.3, built 2023-11-22T20:59:54Z Version Sha: 25a4d1a00dc81a5b4907c76c2358f38d30c05747 ==&gt; Vault server started! Log data will stream in below: ... 2024-02-26T15:59:57.791Z [INFO] events: Starting event system This is a sample usage of the SGX application, as it is, and should not be used in production; unless the above warnings related to sgx.allowed_files related to Gramine are resolved.
+Next steps Deploy the management hub using Helm.
+Add a managed cluster to deploy the managed cluster piece using ACM.
+`,url:"https://validatedpatterns.io/patterns/multicloud-gitops-sgx/",breadcrumb:"/patterns/multicloud-gitops-sgx/"},"https://validatedpatterns.io/patterns/travelops/":{title:"TravelOps",tags:[],content:` About the travelops pattern Use case Use a GitOps approach to manage hybrid and multi-cloud deployments across both public and private clouds.
+Enable cross-cluster governance and application lifecycle management.
+Securely manage secrets across the deployment.
+Based on the requirements of a specific implementation, certain details might differ. However, all validated patterns that are based on a portfolio architecture, generalize one or more successful deployments of a use case.
+Background The {trvlops-pattern} deployed using OpenShift GitOps and is comprised of Red Hat Service Mesh (RHSM), Kiali for the Service Mesh console, Jaeger for distributed tracing, and elasticsearch for logging and analytics. The application deployed is from the Kiali traveldemo tutorial. This pattern isn’t as much about the demo as it is about the capabilities that are enabled with a few simple configurations. Service Mesh’s are being incorporated across multiple platforms to provide secure communications between services.
+Organizations are aiming to develop, deploy, and operate applications on an open hybrid cloud in a stable, simple, and secure way. This hybrid strategy includes multi-cloud deployments where workloads might be running on multiple clusters and on multiple clouds, private or public. This strategy requires an infrastructure-as-code approach: GitOps. GitOps uses Git repositories as a single source of truth to deliver infrastructure-as-code. Submitted code will be checked by the continuous integration (CI) process, while the continuous delivery (CD) process checks and applies requirements for things like security, infrastructure-as-code, or any other boundaries set for the application framework. All changes to code are tracked, making updates easy while also providing version control should a rollback be needed.
+About the solution This architecture covers a single cluster for all DevOps and GitOps functionality. However, one could extend this architecture to meet hybrid or multicloud demand using a GitOps approach
+Benefits of Hybrid Multicloud management with GitOps:
+Unify management across cloud environments.
+Dynamic infrastructure security.
+Infrastructural continuous delivery best practices.
+In the following figure, logically, this solution can be viewed as being composed of an automation component, unified management including secrets management, and the clusters under management, all running on top of a user-chosen mixture of on-premise data centers and public clouds.
+Figure 1. Logical diagram of hybrid multi-cloud management with GitOps About the technology The following technologies are used in this solution:
+Red Hat OpenShift Platform An enterprise-ready Kubernetes container platform built for an open hybrid cloud strategy. It provides a consistent application platform to manage hybrid cloud, public cloud, and edge deployments. It delivers a complete application platform for both traditional and cloud-native applications, allowing them to run anywhere. OpenShift has a pre-configured, pre-installed, and self-updating monitoring stack that provides monitoring for core platform components. It also enables the use of external secret management systems, for example, HashiCorp Vault in this case, to securely add secrets into the OpenShift platform.
+Red Hat OpenShift GitOps A declarative application continuous delivery tool for Kubernetes based on the ArgoCD project. Application definitions, configurations, and environments are declarative and version controlled in Git. It can automatically push the desired application state into a cluster, quickly find out if the application state is in sync with the desired state, and manage applications in multi-cluster environments.
+Red Hat Advanced Cluster Management for Kubernetes Controls clusters and applications from a single console, with built-in security policies. Extends the value of Red Hat OpenShift by deploying apps, managing multiple clusters, and enforcing policies across multiple clusters at scale.
+Red Hat Service Mesh Red Hat® OpenShift Service Mesh provides a uniform way to connect, manage, and observe microservices-based applications.
+Red Hat Ansible Automation Platform Provides an enterprise framework for building and operating IT automation at scale across hybrid clouds including edge deployments. It enables users across an organization to create, share, and manage automation, from development and operations to security and network teams.
+Hashicorp Vault Provides a secure centralized store for dynamic infrastructure and applications across clusters, including over low-trust networks between clouds and data centers.
+This solution also uses a variety of observability tools including the Prometheus monitoring and Grafana dashboard that are integrated with OpenShift as well as components of the Observatorium meta-project which includes Thanos and the Loki API.
+Overview of the architectures The following figure provides a high level architectural overview of the travelops pattern.
+Figure 2. Overview schematic diagram of the complete solution Subsequent schematic diagrams provide details on:
+Hybrid multi-cloud GitOps
+Dynamic security management
+Hybrid Multicloud GitOps The following figure provides a schematic diagram showing remaining activities associated with setting up the management hub and clusters using Red Hat Advanced Cluster Management.
+Figure 3. Schematic diagram of hybrid multi-cloud management with GitOps Manifest and configuration are set as code template in the form of a Kustomization YAML file. The file describes the desired end state of the managed cluster. When complete, the Kustomization YAML file is pushed into the source control management repository with a version assigned to each update.
+OpenShift GitOps monitors the repository and detects changes in the repository.
+OpenShift GitOps creates and updates the manifest by creating Kubernetes objects on top of Red Hat Advanced Cluster Management.
+Red Hat Advanced Cluster Management provisions, updates, or deletes managed clusters and configuration according to the manifest. In the manifest, you can configure what cloud provider the cluster will be on, the name of the cluster, infrastructure node details and worker node. Governance policy can also be applied as well as provision an agent in the cluster as the bridge between the control center and the managed cluster.
+OpenShift GitOps continuously monitors the code repository and the status of the clusters reported back to Red Hat Advanced Cluster Management. Any configuration drift or in case of any failure, OpenShift GitOps will automatically try to remediate by applying the manifest or by displaying alerts for manual intervention.
+Dynamic security management The following figure provides a schematic diagram showing how secrets are handled in this solution.
+Figure 4. Schematic showing the setup and use of external secrets management During setup, the token to securely access HashiCorp Vault is stored in Ansible Vault. It is encrypted to protect sensitive content.
+Red Hat Advanced Cluster Management for Kubernetes acquires the token from Ansible Vault during install and distributes it among the clusters. As a result, you have centralized control over the managed clusters through RHACM.
+To allow the cluster access to the external vault, you must set up the external secret management with Helm in this study. OpenShift Gitops is used to deploy the external secret object to a managed cluster.
+External secret management fetches secrets from HashiCorp Vault by using the token that was generated in step 2 and constantly monitors for updates.
+Secrets are created in each namespace, where applications can use them.
+Next steps Deploy the Pattern using Helm.
+`,url:"https://validatedpatterns.io/patterns/travelops/",breadcrumb:"/patterns/travelops/"},"https://validatedpatterns.io/blog/2024-02-07-hcp-htpasswd-config/":{title:"Adding htpasswd oAuth provider to HCP clusters",tags:[],content:`Configure HTPasswd OAuth provider for hosted clusters Overview In this blog, we&rsquo;re going to configure our hosted cluster to use htpasswd as its authentication provider.
+There are several reasons that we would want to do this, but usually it comes down to understanding that the kubeadmin/root users aren&rsquo;t the right way to do things. HTPasswd is a simple but effective way to centrally manage users and provide access to cluster resources when bound to the proper RBAC. In a traditional OpenShift deployment the configuration of the htpasswd oauth is well documented, but with hosted control planes we have to dig a little bit for the answer. This blog walks through the configuration of the oauth provider, and also provides ways that you can verify the configuration works as intended.
+Assumptions The procedures in this blog have been tested against OpenShift 4.13 and 4.14 hostedclusters.
+This blog assumes that you have the following binaries installed on your machine:
+hcp | Creating and managing hosted clusters htpasswd | Creating and managing htpasswd configurations oc | Interacting with your OpenShift cluster Warning: When you add an idp configuration the kubeadmin password is no longer available. So if you forget the password that you created or you want that level of permissions you will need to generate and use the kubeconfig:
+Getting Started NOTE: The following steps should be performed on the HyperShift management cluster
+Create the kubeconfig for the hosted cluster hcp create kubeconfig –name &lt;clusterName&gt; &gt; /tmp/&lt;clusterName&gt;.kube export KUBECONFIG=/tmp/&lt;cluserName&gt;.kube First, using the htpasswd cli we need to create an htpasswd configuration with our users and their passwords.
+htpasswd -Bbc htpasswd.users admin password
+We&rsquo;re creating a file called htpasswd.users and adding a user called admin with the password of password.
+Next, we need to create a secret in the same namespace as the hostedcluster resource.
+The default namespace is clusters
+There is no required naming convention. However, for the sake of future you and others on your team that may be configuring their clusters with htpasswd appending the cluster name to the end of the secret is a simple and effective way to associate the secret to the hostedcluster.
+Create the secret for your hostedcluster oc create secret generic htpasswd-&lt;clusterName&gt; –from-file=htpasswd=./htpaaswd.users -n clusters
+Now we need to update the hostedcluster resource with the htpasswd OAuth provider:
+Apply OAuth configuration to hostedcluster resource oc edit hostedcluster &lt;clustername&gt; -n clusters
+Add the following to the hostedcluster resource:
+spec: configuration: oauth: identityProviders: - htpasswd: fileData: name: htpasswd-&lt;clusterName&gt; #secret name mappingMethod: claim name: htpasswd #name of the oAuth entry type: HTPasswd You can verify that the configuration is picking up the change correctly by looking at the pod status in clusters-
+Notice the time that the pods have been running, if you see that they have recently been restarted and are without error then this is a good indication that the configuration has been applied correctly.
+oc get pods -n clusters-demo oauth-openshift-54bc55789b-5j854 2/2 Running 0 58s oauth-openshift-54bc55789b-g6bls 1/2 Running 0 26s oauth-openshift-54bc55789b-jtf5m 2/2 Running 0 91s Verification WARNING: The following steps are to be performed on the hostedcluster
+Login using the credentials we created earlier. You can either login to the hosted cluster openshift console or to the api server.
+Something to be aware of: When using the OpenShift console the htpasswd provider will not be presented as a choice for logging in. This is because the kubeadmin user/password is removed when the IDP is updated.
+api server login example: hcp create kubeconfig –name &lt;clusterName&gt; &gt; /tmp/&lt;clusterName&gt;.kube export KUBECONFIG=/tmp/&lt;clusterName&gt;.kube oc login $(oc whoami –show-server) -u admin -p password Apply RBAC to configured user(s) You may notice that your user doesn&rsquo;t really have any permissions to the cluster. You will need to grant permissions to the user by applying a Role or ClusterRole. In this example, we are giving our admin user the cluster-admin clusterRole.
+NOTE: You will likely not have admin access to your cluster so you will need to create and export the kubeconfig for your hosted cluster to apply the RBAC to your user
+oc adm policy add-cluster-role-to-user cluster-admin admin
+Once you have logged in using the htpasswd idp you can view the users and identities that OpenShift is aware of:
+oc get identity,users NAME IDP NAME IDP USER NAME USER NAME USER UID identity.user.openshift.io/htpasswd:admin htpasswd admin admin 25dfddc5-66b4-47c2-8ba2-7b54b72eda04 NAME UID FULL NAME IDENTITIES user.user.openshift.io/admin 25dfddc5-66b4-47c2-8ba2-7b54b72eda04 htpasswd:admin Summary That&rsquo;s it! We took our out of the box hostedcluster and applied an HTPasswd OAuth provider and then applied a clusterRole to it. This is a simple approach for you and your team to share a cluster without having to share the kubeadmin username. Alternatively, if you wanted to use other OIDC authenticators like GitHub, Google ..etc you could follow along with the flow from this blog to accomplish.
+`,url:"https://validatedpatterns.io/blog/2024-02-07-hcp-htpasswd-config/",breadcrumb:"/blog/2024-02-07-hcp-htpasswd-config/"},"https://validatedpatterns.io/blog/2024-03-05-intel-accelerated-patterns/":{title:"Announcing Intel Accelerated Validated Patterns",tags:[],content:`Intel AMX accelerated patterns increase AI performance while reducing cost We are very excited to share that Red Hat has partnered with Intel to deliver not one, but two Red Hat Validated Patterns using Intel® Advanced Matrix Extensions (Intel® AMX) an integrated accelerator on 4th and 5th Generation Intel® Xeon® Scalable processors that increases performance for deep-learning inference and training.
+The goal of Red Hat Validated Patterns is not only to facilitate testing and deployment of complex patterns, but to demonstrate business value by incorporating real-world workloads and use cases. Our extensive partner ecosystem allows us to provide our consumers with a catalog of real deployment architectures that help to accelerate a proof of concept to production, affording decision makers with an informed strategic blueprint that helps to overcome technological challenges.
+Artificial Intelligence (AI) is a common component in several Validated Patterns. The ability to accelerate image recognition, anomaly detection, and AI inference pipelines drives faster innovation in this revolutionary technology shift. With a focus on enhancing AI workloads, Intel integrated their AMX technology with two Validated Patterns—Medical Diagnosis and MultiCloud GitOps. By using the Red Hat Node Feature Discovery (NFD) operator,the engineers targeted and properly scheduled the pattern deployment onto the Intel cluster nodes. With the Medical Diagnosis pattern, Intel was able to demonstrate significantly faster inference of x-ray images at the edge. For the MultiCloud GitOps pattern, the use of Intel® AMX accelerators can provide up to 10x acceleration for inference speeds over previous generation Intel Xeon Scalable Processors.
+Together with other Intel technologies, such as Intel® AI Tools and the OpenVINO™ Toolkit Operator, organizations are poised to advance the benefits of their investment in AI and machine learning (ML). A cornerstone partner for Red Hat OpenShift AI, Intel proves to be an invaluable contributor in this space in addition to other critical business initiatives.
+Built-in accelerators are a revolutionary chip technology feature in Intel 4th and 5th Generation Xeon Scalable Processors with significant promise in addressing real-world workloads, such as network and storage encryption and compression, trusted domains and application security extensions, enhanced processing capacity for data-intensive workloads, and more. Read more about the Intel AMX integration with Validated Patterns in Intel’s recently released reference architecture, and get the documentation for Intel AMX Accelerated MultiCloud GitOps, and Intel AMX Accelerated Medical Diagnosis. This is just the beginning. Intel is currently integrating additional built-in accelerators for Intel® Xeon® processors with Red Hat Validated Patterns. Keep an eye out for new reference architectures featuring other business critical workloads and find additional information and review our catalog of Red Hat Validated Patterns at https://validatedpatterns.io
+`,url:"https://validatedpatterns.io/blog/2024-03-05-intel-accelerated-patterns/",breadcrumb:"/blog/2024-03-05-intel-accelerated-patterns/"},"https://validatedpatterns.io/blog/2024-01-26-more-secrets-options/":{title:"More Secrets Options Now Available with Validated Patterns",tags:[],content:`More Secrets Options Now Available with Validated Patterns Overview One of the things about the kubernetes application management experience that we wanted to explore and improve as part of the Validated Patterns initiative was the secrets handling in GitOps. So we worked out a scheme that stored secret material in a dedicated secrets store, using the External Secrets Operator to project that secret material into the applications using ESO&rsquo;s powerful and convenient abstraction and templating features. At that time, HashiCorp Vault was well supported and popular in the community, as was using ESO to retrieve secrets from it. All of the major hyperscaler keystores are supported (AWS, Azure, GCP), but multi- or hybrid- cloud solutions that can be &ldquo;self-contained&rdquo; are either less well supported or the solutions themselves lean towards SaaS offerings.
+Almost two years later, the secrets landscape has shifted somewhat. As a Red Hat project, Validated Patterns initiative gravitates towards Red Hat-supported solutions, and neither HashiCorp Vault nor ESO are currently Red Hat supported. Meanwhile, the only backend we provided a code path to drive with ESO was Vault.
+This nullifies one of the major reasons we wanted to use ESO in the first place - namely, the ability to easily swap out secrets backends in case Vault was not usable for some reason. Earlier in 2023, one of our engineers did a proof of concept of ESO support using the AWS Secrets Manager backend - demonstrating that ESO delivered on its promise of multiple secret store support. Adapting ESO was the easy part - the hard part is building more abstraction into the VP secrets handling code that runs on pattern install.
+To this end, we decided we would expand secrets support by introducing at least one new backend - and we chose the kubernetes backend, because it is self-contained (that is, it can be run on-prem and requires no new products or projects to be installed), and is a useful vehicle for introducing an abstraction layer for validated patterns secret parsing. In addition, dealing with kubernetes secrets objects directly has the side effect of enabling us to provide a mechanism for users to inject their secrets directly into their patterns, bypassing the need to use any secrets manager or ESO at all. This also provides benefits to installations where only commercially supported solutions can be installed, since ESO is currently not commercially supported by any entity.
+In a nutshell, the new features depend on an abstraction of secret file parsing, so that the secrets are held in memory in a datastructure that is then processed and loaded by the appropriate backend code.
+Users of the pattern framework will be able to change secrets backends as straightforwardly as we can make possible. The only other change the user will need to make (to use another ESO backend) is to use the backend&rsquo;s mechanism to refer to keys. (For example: in Vault, keys have have names like secret/data/global/config-demo; in the Kubernetes backend it would just be the secret object name that&rsquo;s being used to store the secret material, such as config-demo).
+Chart changes The clusterSecretStore related chart elements have moved to values-global.yaml, specifically global.secretStore.backend. For example, from multicloud-gitops:
+global: pattern: multicloud-gitops options: useCSV: false syncPolicy: Automatic installPlanApproval: Automatic secretStore: backend: kubernetes Previously, the secretStore setting was done per-chart; but ordinarily this setting will hold for the entire cluster, which may include many charts. Because of this, we will move these settings in our charts. (Older configs will not break if they still use vault; and it is still an option to override each chart if you want to do that.)
+Individual secret keys used for ESO lookups will need to be overridden or changed to use the kubernetes backend.
+This values-global setting is also used by the Ansible workflow to decide which backend to inject secrets into.
+The &ldquo;vault&rdquo; Backend - Unchanged Interface, New plumbing The vault support now has a new code path to follow, but supports exactly the same features in the same ways it always has. Vault is still the default backend for patterns, and all existing patterns should be able to adopt the new code path without making any changes. Any other experience is a bug we will fix.
+All of the defaults for the new code path are designed to work with existing vault-based configurations; the new features are entirely optional and we do not expect breakage or regressions to existing vault-based configurations.
+The &ldquo;kubernetes&rdquo; Backend new New features have been introduced to the secrets structure to support the use of the Kubernetes ESO backend. See the below details for the new options and how they are processed by the kubernetes parsing strategy.
+The &ldquo;none&rdquo; Backend new New features have been introduced to the secrets structure to support not using an ESO ESO backend, but rather injecting secrets objects directly into the pattern. This violates the spirit of GitOps by not recording the details of the deployment in a versioned way. However users might want or need to make this tradeoff for different reasons. See the below details for the new options and how they are processed by the none parsing strategy.
+At present, any external secret objects will need to be deleted from the repository to use the none backend - since the ArgoCD application will not sync when a non-existing CRD is referenced.
+How to Use a non-default Backend We have provided Makefile targets to switch between backends. These targets edit the pattern configuration files in-place; in keeping with the GitOps philosophy they change the files in git that control how the application is deployed.
+These Makefile targets are:
+secrets-backend-vault Edits values files to use default Vault+ESO secrets config secrets-backend-kubernetes Edits values file to use Kubernetes+ESO secrets config secrets-backend-none Edits values files to remove secrets manager + ESO Run the makefile target in your repo to effect the necessary changes. If the command makes changes, it will display them in git diff format, and it will be up to you to commit and push the result to effect the change. Nothing will change on your cluster until you commit and push.
+Using the old system - The legacy-load-secrets Makefile target The existing vault-utils codepath is available via the legacy-load-secrets Makefile target. If secrets loading fails, or you just want to use the other system, you can run make legacy-load-secrets after make install and it will run those scripts and the Ansible playbooks and roles associated with them.
+Deprecation of v1.0 Secrets The v1.0 secrets format has not been used in the Validated Patterns framework for over a year now. The v2.0 framework is a strict superset of the v1.0 framework. Support for the v1.0 framework is still available via the legacy-load-secrets code path, but this may be removed in the future.
+Updates to the Secrets v2.0 Schema New features have been added at both the file level and the per-secret level to support the new backends:
+Top-level Additions secretStoreNamespace example:
+--- version: &#34;2.0&#34; secretStoreNamespace: &#39;validated-patterns-secrets&#39; secrets: A new top-level key has been introduced in the secrets file: secretStoreNamespace. This defaults to validated-patterns-secrets. This is the namespace that ESO uses as its special secret store, which serves the same architectural purpose as vault does in the default installation. (Secrets are installed into this namespace as Kubernetes secrets objects, and ESO allows for them to be copied or templated out using ESO mechanisms).
+defaultAnnotations example:
+defaultAnnotations: validatedpatterns.io/pattern: &#39;myPattern&#39; This data structure is a hash, or dictionary. These labels will be applied to all secrets objects unless they have per-secret annotations set. Labels are only added to kubernetes based secrets objects (using the kubernetes or none) backends. The vault loader ignores these settings.
+defaultLabels example:
+defaultLabels: patternType: &#39;edge&#39; patternEnvironment: &#39;production&#39; This data structure is a hash, or dictionary. These labels will be applied to all secrets objects unless they have per-secret labels set. Labels are only added to kubernetes based secrets objects (using the kubernetes or none) backends. The vault loader ignores these settings.
+Per-secret Additions targetNamespaces example:
+secrets: - name: config-demo targetNamespaces: - config-demo fields: This option is ignored by vault and kubernetes backends, and only used by the none backend. Normally, you will only need to add your secret to one namespace at a time. However, if you do need to copy a secret that is identical except for the namespace it goes into, you can add multiple targetNamespaces each namespace specified will get a copy of the secret.
+There is not a default target namespace for the none backend, so omitting this field from a config parsed for the none backend is an error.
+labels example:
+secrets: - name: config-demo labels: patternType: &#39;edge&#39; patternEnvironment: &#39;production&#39; fields: In this case, these labels will only be applied to any config-demo secret objects created by the framework. This option is only used by the none and kubernetes backends and ignored by the vault backend. If defaultLabels are specified at the top level of the file, per-secrets labels will override them.
+annotations example:
+secrets: - name: config-demo annotations: validatedpatterns.io/pattern: &#39;myPattern&#39; fields: In this case, this annotation will only be applied to any config-demo secret objects created by the framework. This option is only used by the none and kubernetes backends and ignored by the vault backend. If defaultAnnotations are specified at the top level of the file, per-secrets annotations will override them.
+Under the Hood - Python and Ansible Code The main changes here were to factor out the code that did the file parsing and actual secret loading into different modules. The parse_secrets_info module now reads all of the file contents and renders all of the secrets it can before turning the process over to an appropriate secrets loader.
+The process_secrets playbook The process_secrets understands the backend configured for the different backends from values-global, and follows the appropriate strategy.
+parse_secrets_info Ansible Module parse_secrets_info understands the different backends, and parses the secrets file into an in-memory structure that can then be handed over to a loader specific to the backend. There is an additional script, common/scripts/process_secrets/display-secrets-info.sh &lt;secrets_file&gt; &lt;backend_type&gt; that can be used to view how the secrets are parsed. This will display secrets on the terminal, so use with caution. It creates a parsed_secrets structure that should be generally useful, as well as vault_policies (Specifically for Vault support). Additionally, it creates a kubernetes_secret_objects structure suitable to hand over to the Ansible k8s.core collection directly.
+vault_load_parsed_secrets Ansible Module vault_load_parsed_secrets is responsible for setting up the commands to load the secrets into vault, and running them.
+The k8s_secret_utils Ansible Role k8s_secret_utils is used for loading both the kubernetes and none backends. It
+Changes to to vault_utils Ansible Role Some code has been factored out of vault_utils and now lives in roles called cluster_pre_check and find_vp_secrets roles. A new task file has been added, push_parsed_secrets.yaml that knows how to use the parsed_secrets structure generated by parse_secrets_info. The existing code in the other task files remains.
+Developing a new backend To provide support for an additional backend, the framework will need changes to:
+The golang-external-secrets chart (to support the new provider) The shell and ansible framework for loading (understanding the new backend name and developing behaviors for it). Conclusion The Validated Patterns framework strives to offer solutions to real-world problems, and we hope you will find these new features useful. If you run into problems, we will do our best to help!
+`,url:"https://validatedpatterns.io/blog/2024-01-26-more-secrets-options/",breadcrumb:"/blog/2024-01-26-more-secrets-options/"},"https://validatedpatterns.io/blog/2024-01-16-deploying-mcg-with-cisco-flashstack-portworx/":{title:"Deploying Multicloud GitOps with Cisco FlashStack Data Center and Portworx Enterprise",tags:[],content:`Deploying Multicloud GitOps with Cisco FlashStack Data Center and Portworx Enterprise The Validated Patterns team, in partnership with Cisco Compute Solutions Technical Marketing team led by Paniraj Koppa, has delivered a white paper detailing how to deploy the MultiCloud GitOps Validated Pattern with the Cisco FlashStack Data Center platform. This platform integrates Cisco Unified Computing System (UCS), Cisco Networking, Pure Storage FlashArray and Portworx Enterprise Kubernetes Storage Platform with Red Hat® OpenShift®. Cisco&rsquo;s distinction as the first OEM partner to validate the Multicloud GitOps Validated Pattern on-premises, utilizing their leading-edge Cisco hardware, reinforces the depth of their partnership and collaborative efforts with Red Hat.
+In the dynamic realm of enterprise IT, the demand for seamless application deployment across diverse cloud environments has reached a critical point. Enter Cisco&rsquo;s groundbreaking solution—a fusion of Multicloud GitOps validated patterns and the robust FlashStack Data Center infrastructure. The FlashStack for Hybrid Multicloud GitOps White Paper, published by Cisco, offers a comprehensive guide that unveils the architectural nuances, best practices, and a deep dive into the technologies driving this innovative deployment framework.
+At the core of this solution lies Cisco&rsquo;s FlashStack Data Center, a robust and scalable infrastructure designed to support diverse workload requirements. The hardware and software components employed in Cisco&rsquo;s internal labs validate the efficacy of this solution, ensuring a reliable and efficient deployment framework.
+In this white paper, Cisco outlines the hardware and software components and how they provide value for cloud-native workloads delivered across a hybrid cloud environment. The Cisco FlashStack solution provides an outstanding unified system to deliver robust, business critical applications. Red Hat&rsquo;s Multicloud GitOps Validated Pattern delivers a codified GitOps framework for deploying and configuring distributed software architectures in a predictable, repeatable, and extensible manner. By combining a ready-built system infrastructure with a validated deployment solution for Red Hat OpenShift, Portworx Enterprise, and other core software components, organizations can accelerate the time to value for a modern application development and deployment platform. Notably, the flexibility of this solution extends beyond the unified hardware infrastructure and incorporates a complete cloud-native application development and deployment platform with key management, security, registry, and cluster data management services.
+The deployment of Red Hat OpenShift Container Platform serves as a cornerstone of this solution. The Multicloud GitOps Validated Pattern seamlessly deploys additional solution components, such as Red Hat Advanced Cluster Management, Red Hat OpenShift GitOps, and Portworx Enterprise providing a complete platform. Leveraging the robustness of Cisco UCS server platforms, organizations can manage and orchestrate containerized applications on-premises and across multi cloud environments. The versatility of Red Hat OpenShift, coupled with the reliability of Cisco UCS servers, forms a powerful synergy driving efficiency and performance.
+Not only does the Cisco white paper provide an architectural blueprint; it also addresses critical considerations and best practices imperative for a successful deployment. From architectural nuances to operational best practices, enterprises gain insights into optimizing their infrastructure for Multicloud GitOps, ensuring a smooth and efficient deployment experience.
+This adaptability allows organizations to tailor their infrastructure configurations based on specific performance or scalability requirements.
+The Multicloud GitOps Validated Pattern deployment guidance provided in the Cisco white paper, coupled with the robustness of Cisco FlashStack Data Center, forms a compelling solution for organizations seeking to streamline deployment and configuration of a cloud native application development and deployment platform. The integration of Red Hat OpenShift on Cisco UCS servers presents a flexible and efficient architecture for modern, agile businesses. The synergy of these technologies within the Multicloud Gitops Validated Pattern, supported by FlashStack Data Center infrastructure, heralds a new era of agile, scalable, and efficient application deployments for organizations adopting modern application practices.
+For more detailed information please refer to the FlashStack for Hybrid Multicloud GitOps White Paper published by Cisco, and learn more about the MultiCloud GitOps pattern as well as other popular Validated Patterns at validatedpatterns.io.
+`,url:"https://validatedpatterns.io/blog/2024-01-16-deploying-mcg-with-cisco-flashstack-portworx/",breadcrumb:"/blog/2024-01-16-deploying-mcg-with-cisco-flashstack-portworx/"},"https://validatedpatterns.io/blog/2023-12-20-private-repos/":{title:"Private Repositories",tags:[],content:`We&rsquo;re excited to announce that support for private repositories is now available. This feature is accessible when using VP operator version 0.0.36 or higher, in conjunction with the latest common/ clustergroup 0.8.2 chart. With this update, you can deploy patterns from git repositories that are either password-protected or secured with an SSH key.
+To enable this feature, follow these steps:
+Create a Secret for Repository Access: Generate a secret that holds the credentials for accessing your repository. This secret should be formatted according to ArgoCD&rsquo;s guidelines, which you can find here. For instance, your secret might look like this: apiVersion: v1 kind: Secret metadata: name: private-repo namespace: openshift-operators labels: argocd.argoproj.io/secret-type: repository stringData: type: git url: git@github.com:mbaldessari/mcg-private.git sshPrivateKey: | -----BEGIN OPENSSH PRIVATE KEY----- a3... ... ... -----END OPENSSH PRIVATE KEY----- Deploy the Pattern with the Secret: Point your pattern&rsquo;s Custom Resource to the secret you created in the first step. Ensure that both tokenSecret and tokenSecretNamespace fields are correctly set to reference your new secret. Here&rsquo;s an example of how this might be configured: apiVersion: gitops.hybrid-cloud-patterns.io/v1alpha1 kind: Pattern metadata: name: pattern-sample namespace: openshift-operators spec: clusterGroupName: hub gitSpec: targetRepo: git@github.com:mbaldessari/mcg-private.git targetRevision: private-repo tokenSecret: private-repo tokenSecretNamespace: openshift-operators Following these steps ensures that the pattern&rsquo;s framework efficiently manages the necessary configurations, allowing all Argo instances to access the private repository.
+To do this entirely via CLI you can simply run the following:
+./pattern.sh make TOKEN_SECRET=private-repo TOKEN_NAMESPACE=openshift-operators install The above command assumes that the private-repo secret exists and that the origin remote of the repository points to git@github.com:mbaldessari/mcg-private.git as specified in the secret above.
+`,url:"https://validatedpatterns.io/blog/2023-12-20-private-repos/",breadcrumb:"/blog/2023-12-20-private-repos/"},"https://validatedpatterns.io/blog/2023-12-15-understanding-namespaces/":{title:"Understanding Namespace Creation using the Validated Patterns Framework",tags:[],content:`Understanding Namespace Creation using the Validated Patterns Framework In the realm of Kubernetes and containerized environments, managing namespaces efficiently is pivotal. It ensures proper organization, security, and resource isolation within a cluster. With the Validated Patterns framework, creating namespaces becomes not just systematic but also highly customizable.
+In this blog we will talk about the different ways to create namespaces by describing them in the Validated Patterns values files. We provide examples of the different options we support and the reasoning behind them.
+Describing Namespaces in the Validated Patterns values files Namespaces in Kubernetes offer a way to divide cluster resources between multiple users, teams, or projects. They act as virtual clusters within a physical cluster, enabling isolation and segmentation.
+The Validated Patterns framework provides a structured approach to creating namespaces, allowing for a range of configurations to meet specific requirements. In addition, the Validated Patterns framework, by default, creates an Operator Group, defined by the OperatorGroup resource, which provides multi-tenant configuration to OLM-installed Operators.
+The namespaces: Configuration structure The Validated Patterns values files have several required sections that fall under the clusterGroup: top level section. The structure to describe namespaces starts with the declaration of the namespaces: section in the values-*.yaml files.
+clusterGroup: name: example isHubCluster: true sharedValueFiles: - /values/{{ .Values.global.clusterPlatform }}.yaml - /values/{{ .Values.global.clusterVersion }}.yaml namespaces: … The Validated Patterns framework, defined by the clusterGroup helm chart in the common github repository, accepts two formats for the namespaces: section:
+A list object A map object If a namespace is described as a list item the Validated Patterns framework will use that list element and create a Namespace resource, using that name, as well as an OperatorGroup resource. By default the Validated Patterns framework will add the namespace to the spec.targetNamespaces for the OperatorGroup resource.
+If a namespace is described as a map object, e.g. mynamespace:, the Validated Patterns framework will look for additional elements in the namespace description. The elements that the Validated Patterns framework looks for are labels:, annotations:, operatorGroup: and targetNamespaces:.
+The Validated Patterns framework uses a JSON Schema for defining the structure of JSON data for the values files. It provides a contract for what JSON data is required for a given application and how to interact with it. We use the JSON Schema file mostly for validation, documentation, and interaction control of JSON data. You can find the JSON Schema for the clusterGroup: section in our Validated Patterns common github repository.
+Let&rsquo;s explore the various methods to create namespaces using the Validated Patterns framework, examining the configurations provided.
+Describing namespaces using a list We mentioned that if you describe a namespace as a list the Validated Patterns framework will use that list element and create a Namespace resource, using that name, as well as an OperatorGroup resource. By default the Validated Patterns framework will use the namespace as the targetNamespace value for the OperatorGroup resource.
+You can use both a list, and a map object, to describe a namespace. Here’s an example of using a list to describe a namespace.
+namespaces: - open-cluster-management - vault - golang-external-secrets - config-demo - hello-world A namespace will be created for each one of the items in the list as well as an operator group with the namespace included in the targetNamespaces list.
+For example, the Validated Patterns framework will generate a Namespace manifest for the namespace hello-world.
+# Source: clustergroup/templates/core/namespaces.yaml apiVersion: v1 kind: Namespace metadata: labels: argocd.argoproj.io/managed-by: common-hub name: hello-world spec: In addition, the Validated Patterns framework will generate a default OperatorGroup manifest.
+# Source: clustergroup/templates/core/operatorgroup.yaml apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: hello-world-operator-group namespace: hello-world spec: targetNamespaces: - hello-world By default we include the namespace in the list of targetNamespaces:.
+Adding Labels and Annotations to a namespace In OpenShift, or Kubernetes, you can use labels and annotations as a method to organize, group, or select API objects. Labels can be used to group arbitrarily-related objects; for example, our Validated Patterns framework labels the OpenShift GitOps applications resources with labels so that we can identify application resources that were created by the Validated Patterns framework.
+To define labels and annotations you would describe the namespace as a map object, adding the labels and annotations needed, using the following structure in the values.yaml file:
+namespaces: - open-cluster-management: labels: openshift.io/node-selector: &#34;&#34; kubernetes.io/os: linux annotations: openshift.io/cluster-monitoring: &#34;true&#34; owner: &#34;namespace owner&#34; The Validated Patterns framework will generate the following namespace manifest for the above example.
+--- # Source: clustergroup/templates/core/namespaces.yaml apiVersion: v1 kind: Namespace metadata: name: open-cluster-management labels: argocd.argoproj.io/managed-by: common-example kubernetes.io/os: &#34;linux&#34; openshift.io/node-selector: &#34;&#34; annotations: openshift.io/cluster-monitoring: &#34;true&#34; owner: &#34;namespace owner&#34; spec: This configuration exemplifies the use of labels and annotations to define properties for the namespace. Labels assist in grouping namespaces while annotations provide additional metadata.
+Adding an OperatorGroup with a list of targetNamespaces You can explicitly name the target namespace for an Operator group using the spec.targetNamespaces parameter. The Validated Patterns framework allows to specify a list of targetNamespaces in the description of a namespace.
+namespaces: - application-ci: operatorGroup: true targetNamespaces: - application-ci - other-namespace Here, the operatorGroup is set to true, which tells the Validated Patterns framework that you would like to create the OperatorGroup resource, and describes a set of namespaces where an operator will be active. The targetNamespaces specifies the namespaces that will be affected by this operator.
+The generated manifest for the OperatorGroup will look like this:
+--- # Source: clustergroup/templates/core/operatorgroup.yaml apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: application-ci-operator-group namespace: application-ci spec: targetNamespaces: - application-ci - other-namespace Excluding targetNamespaces from an OperatorGroup When creating OperatorGroups it is important to keep in mind that an operator may not support all namespace configurations. For example, an operator that is designed to run at the cluster level shouldn’t be expected to work in an OperatorGroup that defines a single targetNamespace.
+namespaces: - exclude-targetns: operatorGroup: true targetNamespaces: Here, the operatorGroup is set to true, which tells the Validated Patterns framework that you would like to create the OperatorGroup resource, and describes an empty targetNamespaces which specifies that this is a global Operator group, which selects all namespaces.
+--- # Source: clustergroup/templates/core/operatorgroup.yaml apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: exclude-targetns-operator-group namespace: exclude-targetns spec: targetNamespaces: Excluding the creation of an Operator Group for a namespace In the case where you don’t want the Validated Patterns framework to create an OperatorGroup resource for a namespace you can do that by describing the namespace as follows:
+namespaces: - exclude-og: operatorGroup: false Here, operatorGroup is set to false, indicating a complete exclusion of an Operator Group resource for the namespace, exclude-og.
+Leveraging Validated Patterns for flexible Namespace creation The Validated Patterns framework offers a structured approach to namespace creation, providing flexibility and control over namespace configurations. By utilizing labels, annotations, and directives like operatorGroup: and targetNamespaces:, administrators can craft namespaces tailored to specific use cases and operational needs within a Kubernetes environment.
+Conclusion Effective namespace management is crucial in Kubernetes environments, and the Validated Patterns framework simplifies and standardizes this process. By understanding the nuances of namespace configurations within the Validated Patterns framework, administrators can efficiently organize and control resources while ensuring security and isolation across the cluster.
+`,url:"https://validatedpatterns.io/blog/2023-12-15-understanding-namespaces/",breadcrumb:"/blog/2023-12-15-understanding-namespaces/"},"https://validatedpatterns.io/blog/2023-12-05-nutanix-testing/":{title:"Pattern Testing on Nutanix",tags:[],content:`I am pleased to announce the addition of the Nutanix platform to our CI dashboard for the Multi-cloud GitOps pattern.
+Pattern consumers can now rest assured that the core pattern functionality will remain functional for deployments of OpenShift on the Nutanix platform.
+This would not be possible without the wonderful co-operation of Nutanix, who are doing all the work of deploying OpenShift and our pattern on their platform, executing the tests, and reporting the results.
+To facilitate this, the patterns team have begun the process of open sourcing the downstream tests for all our patterns. Soon all tests will live alongside the the patterns they target, allowing them to be easily executed and/or improved by pattern consumers and platform owners.
+Our thanks once again to Nutanix.
+`,url:"https://validatedpatterns.io/blog/2023-12-05-nutanix-testing/",breadcrumb:"/blog/2023-12-05-nutanix-testing/"},"https://validatedpatterns.io/blog/2023-12-01-new-pattern-tiers/":{title:"Introducing a Simplified Tier Naming Scheme",tags:[],content:`The efforts here started off with 2 different classes of patterns: “Community” and “Validated”, however this terminology dates back to before the effort had arrived at “Validated Patterns” as the official project name.
+Having standardized on the use of “Validated Patterns” to refer to the overall initiative, it became confusing to refer to “Community” Validated Patterns and “Validated” Validated Patterns.
+In addressing that confusion, we took the opportunity to design a new set of tiers:
+Sandbox (details) Tested (details) Maintained (details) Generally speaking, Sandbox aligns with the old Community tier, and Maintained aligns with the old Validated tier. However some of the requirements associated with those previous tiers were structured around our bandwidth and our priorities. In revisiting the tiers, we’ve removed many of those value judgements and shifted the emphasis to be on where the bar is, rather than who the work is being done by.
+With a new set of tier names, and a new set of requirements, we are going to start off all patterns in the Sandbox tier rather than grandfather them into the new names. Don’t panic, the code behind your favorite patterns have not suddenly regressed, we’re using the opportunity to work out any kinks in the promotion process and ensure patterns are classified consistently.
+We expect to have finished re-reviewing the previous validated tier patterns by the end of 2023 and the previous community tier patterns by the end of Q1 2024.
+`,url:"https://validatedpatterns.io/blog/2023-12-01-new-pattern-tiers/",breadcrumb:"/blog/2023-12-01-new-pattern-tiers/"},"https://validatedpatterns.io/blog/2023-11-17-argo-configmanagement-plugins/":{title:"Argo CD Config Management Plugins in Validated Patterns",tags:[],content:`Argo CD Configuration Management Plugins and the Validated Patterns Framework Problem Argo CD has a number of mechanisms for facilitating Kubernetes application deployments besides applying raw manifests. The most prominent mechanisms it uses are Kustomize (which is built into kubectl now) and Helm (which is an external tool still). If the user has additional needs for manifest generation that cannot be met by either of these tools, Argo CD provides a mechanism called Configuration Management Plugins that allow for editing the manifest stream either in addition to or in lieu of Helm or Kustomize. This mechanism allows, for example, using both Helm and Kustomize on the same template files and/or bases at the same time. If the user needs a custom tool, such as PolicyGen to be involved in generating Kubernetes manifests, this feature enables its use. Similarly, another use for this feature is to enable the Argo CD Vault Plugin, which works by substituting specific tags in manifests. This allows users to avoid storing secrets directly in git repositories, which is one of the key needs of an operational GitOps strategy.
+Implementation The implementation in the Validated Patterns framework is meant to conform to the mechanism described here upstream. Note that the plugin configuration actually must live inside the container - either &ldquo;baked in&rdquo; to the sidecar image, or injected via configmap. The framework supports both options.
+Previously, the Validated Patterns clusterGroup chart would create three plugins using the CMP 1.0 framework. Only one of these was ever used (to the best of our knowledge), helm-with-kustomize in the Industrial Edge pattern. As of this publication, the kustomize integration is no longer necessary - the code was refactored to operate directly on helm value files instead of creating dynamic kustomize patches.
+In the clusterGroup chart (which is the heart of the Validated Patterns framework), there is a new key, argoCD, that can optionally be used to implement an arbitrary number of CMP 2.0-style plugins.
+For example:
+argoCD: initContainers: [] configManagementPlugins: - name: helm-with-kustomize image: quay.io/hybridcloudpatterns/utility-container:latest imagePullPolicy: Always pluginArgs: - &#39;--loglevel=debug&#39; pluginConfig: | apiVersion: argoproj.io/v1alpha1 kind: ConfigManagementPlugin metadata: name: helm-with-kustomize spec: preserveFileMode: true init: command: [&#34;/bin/sh&#34;, &#34;-c&#34;] args: [&#34;helm dependency build&#34;] generate: command: [&#34;/bin/bash&#34;, &#34;-c&#34;] args: [&#34;helm template . --name-template \${ARGOCD_APP_NAME:0:52} -f $(git rev-parse --show-toplevel)/values-global.yaml -f $(git rev-parse --show-toplevel)/values-{{ .Values.clusterGroup.name }}.yaml --set global.repoURL=$ARGOCD_APP_SOURCE_REPO_URL --set global.targetRevision=$ARGOCD_APP_SOURCE_TARGET_REVISION --set global.namespace=$ARGOCD_APP_NAMESPACE --set global.pattern={{ .Values.global.pattern }} --set global.clusterDomain={{ .Values.global.clusterDomain }} --set global.hubClusterDomain={{ .Values.global.hubClusterDomain }} --set global.localClusterDomain={{ coalesce .Values.global.localClusterDomain .Values.global.hubClusterDomain }} --set clusterGroup.name={{ .Values.clusterGroup.name }} --post-renderer ./kustomize&#34;] initContainers is an array of initContainers that will be added to the repo-server pod. In most cases you do not need to do this. (By default, an init container in the repo-server pod will copy the argocd binary into /var to run as the cmp server for the container. This behavior will happen even if you specify nothing here, which is the default. Since the argocd kind supports this, so do we.)
+configManagementPlugins is an array. Each element will add one sidecar plugin to the GitOps repo-server pod the clusterGroup chart controls. In the argoCD instance it primarily adds elements to the sidecarContainers property.
+The name element is the name of the plugin - this is how applications can specifically request that Argo CD/GitOps process the manifests. This name is also used to compose a configmap name if the user specifies the pluginConfig string.
+The image element is the image the sidecar will use. The repo-server default initContainer will copy the argocd server into the image; the user must supply any external binaries though.
+The imagePullPolicy element is optional. It defaults to Always if not specified.
+The pluginArgs element is optional, and is an array. If omitted, it does not have a default. It can be used to turn up the debug level of the cmp-server process inside the container.
+The pluginConfig element is a string, and is optional. If specified, it will be passed through the Helm tpl function, so any recognized Helm variables or functions will be rendered. The chart will arrange for this string to be injected into the sidecar as plugin.yaml via configmap. While it is possible to bake this into the sidecar, changes to the plugin.yaml would require the sidecar image to be rebuilt and redeployed, and the repo-server pod restarted. It is a documented method in the upstream documentation, so the framework allows it.
+Please note that the preserveFileMode setting in the example plugin config is not yet supported in Argo CD 2.6/GitOps Operator 1.8, but is in Argo CD 2.8/GitOps Operator 1.10. The main use for this property is to call executables inside the repository as post-renderers (as this example does). Please be aware that there are security concerns associated with doing this. The suggested practice is to ship any executable programs (including shell scripts, Python scripts etc.) as part of the sidecar image.
+History How CMPs came into the Validated Patterns Framework In the beginning, the Validated Patterns framework had not yet developed its preference (though not, as occasionally reported, an insistence) for Helm, and most of the existing gitops repositories were based on kustomize. The first pattern implemented with the framework was industrial-edge. This was based on the MANUela demo, which was completely based on kustomize.
+We developed the Validated Patterns framework, to some degree, around what the industrial-edge pattern needed. One of the things we wanted to do was to find ways to allow the framework to be used to instantiate a demo without requiring the user to configure things that could be automatically discovered from the environment. So - the user has to configure their own credentials for connecting to git forges and container registries; but the domain the OpenShift cluster that will be running the demo can be discovered, so rather than requiring that to be configured, we provided a mechanism that extracted that information and stored it as a Helm variable. Meanwhile, the components of industrial-edge that used this information had very opinionated kustomize-based deployment mechanisms and workflows to update them. We did not want to change this mechanism at the time, so it was better for us to work out how to apply Helm templating on top of a set of of manifests that kustomize had already rendered. The CMP 1.0 framework was suitable for this, and fairly straightforward to use, so we did. However, we did not, at that time, put any thought into parameterizing the use of config management plugins; making too radical a change to how the repo server worked would have difficult, and would have required injecting a new (and unsupported) image into a product; not something to be undertaken lightly. Finally, it was unclear that there would be significant demand for such a feature in the framework.
+Questions that arose around CMPs in the Validated Patterns Framework Of course, there is some common wisdom about making assumptions in situations like this. Two major factors caused us to revisit the question of config management plugins in the framework. First, one of our prospective users clearly had an architectural need of the framework that was best met using config management plugins; and upstream, Argo CD had come up with an entirely new mechanism for implementing CMPs using sidecars. This took the question of rebuilding or substituting the repo-server image off the table; but required some changes in the framework to accommodate the new mechanism. Secondly, we learned that the existing plugin framework had been deprecated and was at risk of being removed. It was actually removed upstream in Argo CD 2.9.
+Now that the framework supports user-specified sidecar plugins, we would love to hear your feedback. Does our adoption of CMP 2.0 meet your needs? Please engage with us in our upstream issue tracker.
+`,url:"https://validatedpatterns.io/blog/2023-11-17-argo-configmanagement-plugins/",breadcrumb:"/blog/2023-11-17-argo-configmanagement-plugins/"},"https://validatedpatterns.io/patterns/hypershift/":{title:"HyperShift",tags:[],content:`About the HyperShift pattern (hosted control plane) Background This pattern simplifies the deployment of an hosted control plane or hosted control plane cluster. Use this pattern to create hosted control plane clusters.
+Workflow Install multicluster engine for Kubernetes Operator
+Create an instance of the MultiClusterEngine to enable hypershift, which is a technology preview feature.
+Install the AWS Controllers for Kubernetes - Amazon S3 Operator
+Create an S3 bucket that hosted control plane will use for OpenID Connect (OIDC)
+Create a buildconfig and imagestream that provide the HyperShift cli (hypershift) as an imagestream to be used in further automation if desired.
+Figure 1. source: https://hypershift-docs.netlify.app/ If you have any questions or concerns contact Jonny Rickard.
+About the solution elements The solution enables the rapid provisioning of hosted control plane.
+The HyperShift pattern uses the following products and technologies:
+Red Hat OpenShift Container Platform for container orchestration
+Red Hat OpenShift GitOps, a GitOps continuous delivery (CD) solution
+The multicluster engine for Kubernetes Operator, the multicluster-engine provider
+AWS Controllers for Kubernetes - Amazon S3 Operator, an S3 storage controller
+`,url:"https://validatedpatterns.io/patterns/hypershift/",breadcrumb:"/patterns/hypershift/"},"https://validatedpatterns.io/patterns/mlops-fraud-detection/":{title:"MLOps Fraud Detection",tags:[],content:` About the MLOps Fraud Detection MLOps Credit Card Fraud Detection use case Build and train models in RHODS to detect credit card fraud
+Track and store those models with MLFlow
+Serve a model stored in MLFlow using RHODS Model Serving (or MLFlow serving)
+Deploy a model application in OpenShift that runs sends data to the served model and displays the prediction
+Background AI technology is already transforming the financial services industry. AI models can be used to make rapid inferences that benefit the FS institute and its customers. This pattern deploys a AI model to detect fraud on crdit card transactions
+About the solution The model is built on a Credit Card Fraud Detection model, which predicts if a credit card usage is fraudulent or not depending on a few parameters such as: distance from home and last transaction, purchase price compared to median, if it’s from a retailer that already has been purchased from before, if the PIN number is used and if it’s an online order or not.
+Technology Highlights: Event-Driven Architecture
+Data Science on OpenShift
+Model registry using MLFlow
+Solution Discussion This architecture pattern demonstrates four strengths:
+Real-Time Processing: Analyze transactions in real-time, quickly identifying and flagging potentially fraudulent activities. This speed is crucial in preventing unauthorized transactions before they are completed.
+Pattern Recognition: Detect patterns and anomalies in data and learn from historical transaction data to identify typical spending patterns of a cardholder and flag transactions that deviate from these patterns.
+Cost Efficiency: By automating the detection process, AI reduces the need for extensive manual review of transactions, which can be time-consuming and costly.
+Flexibility and Agility: An cloud native architecture that supports the use of microservices, containers, and serverless computing, allowing for more flexible and agile development and deployment of AI models. This means faster iteration and deployment of new fraud detection algorithms.
+Demo Video Overview of the solution for credit card fraud detection Overview of the Architecture Description of each component:
+Data Set: The data set contains the data used for training and evaluating the model we will build in this demo.
+RHODS Notebook: We will build and train the model using a Jupyter Notebook running in RHODS.
+MLFlow Experiment tracking: We use MLFlow to track the parameters and metrics (such as accuracy, loss, etc) of a model training run. These runs can be grouped under different &#34;experiments&#34;, making it easy to keep track of the runs.
+MLFlow Model registry: As we track the experiment we also store the trained model through MLFlow so we can easily version it and assign a stage to it (for example Staging, Production, Archive).
+S3 (ODF): This is where the models are stored and what the MLFlow model registry interfaces with. We use ODF (OpenShift Data Foundation) according to the MLFlow guide, but it can be replaced with another solution.
+RHODS Model Serving: We recommend using RHODS Model Serving for serving the model. It’s based on ModelMesh and allows us to easily send requests to an endpoint for getting predictions.
+Application interface: This is the interface used to run predictions with the model. In our case, we will build a visual interface (interactive app) using Gradio and let it load the model from the MLFlow model registry.
+Figure 1. Overview of the solution reference architecture About the technology The following technologies are used in this solution:
+Red Hat OpenShift Container Platform An enterprise-ready Kubernetes container platform built for an open hybrid cloud strategy. It provides a consistent application platform to manage hybrid cloud, public cloud, and edge deployments. It delivers a complete application platform for both traditional and cloud-native applications, allowing them to run anywhere. OpenShift has a pre-configured, pre-installed, and self-updating monitoring stack that provides monitoring for core platform components. It also enables the use of external secret management systems, for example, HashiCorp Vault in this case, to securely add secrets into the OpenShift platform.
+Red Hat OpenShift AI Red Hat® OpenShift® AI is an AI-focused portfolio that provides tools to train, tune, serve, monitor, and manage AI/ML experiments and models on Red Hat OpenShift. Bring data scientists, developers, and IT together on a unified platform to deliver AI-enabled applications faster.
+Red Hat OpenShift GitOps A declarative application continuous delivery tool for Kubernetes based on the ArgoCD project. Application definitions, configurations, and environments are declarative and version controlled in Git. It can automatically push the desired application state into a cluster, quickly find out if the application state is in sync with the desired state, and manage applications in multi-cluster environments.
+Red Hat AMQ Streams Red Hat AMQ streams is a massively scalable, distributed, and high-performance data streaming platform based on the Apache Kafka project. It offers a distributed backbone that allows microservices and other applications to share data with high throughput and low latency. Red Hat AMQ Streams is available in the Red Hat AMQ product.
+Hashicorp Vault (community) Provides a secure centralized store for dynamic infrastructure and applications across clusters, including over low-trust networks between clouds and data centers.
+MLFlow Model Registry (community) A centralized model store, set of APIs, and UI, to collaboratively manage the full lifecycle of an MLflow Model. It provides model lineage (which MLflow experiment and run produced the model), model versioning, model aliasing, model tagging, and annotations.
+Other This solution also uses a variety of observability tools including the Prometheus monitoring and Grafana dashboard that are integrated with OpenShift as well as components of the Observatorium meta-project which includes Thanos and the Loki API.
+Next steps Deploy the management hub using Helm.
+`,url:"https://validatedpatterns.io/patterns/mlops-fraud-detection/",breadcrumb:"/patterns/mlops-fraud-detection/"},"https://validatedpatterns.io/patterns/medical-diagnosis-amx/":{title:"Intel AMX accelerated Medical Diagnosis",tags:[],content:`About the Medical Diagnosis pattern Background This validated pattern is a modified version of the Medical Diagnosis pattern. It was extended to showcase 5th Generation Intel Xeon Scalable Processors capabilities, especially Intel AMX that speeds up AI workloads. The pattern is based on a demo implementation of an automated data pipeline for chest X-ray analysis that was previously developed by Red Hat. It includes the same functionality as the original demonstration, but uses the GitOps framework to deploy the pattern including Operators, creation of namespaces, and cluster configuration.
+Compared to the original Medical Diagnosis pattern, this one was extended by the Node Feature Discovery Operator, whose task is to detect hardware features and expose them as labels for this node. Red Hat OpenShift Serverless component is modified to assign AI workload to nodes with available Intel AMX feature.
+Moreover, the Machine Learning model was quantized to int8 precision to improve efficiency thanks to Intel AMX, with only marginal accuracy loss.
+This pattern was also adapted to run in on-premise environments.
+Workflow Node Feature Discovery operator labels nodes with Intel AMX capabilities.
+Ingest chest X-rays from a simulated X-ray machine and puts them into an objectStore based on Ceph.
+The objectStore sends a notification to a Kafka topic.
+A KNative Eventing listener to the topic triggers a KNative Serving function.
+KNative Serving was modified to schedule pods with AI workload only on nodes with enabled Intel AMX feature
+An ML-trained model running in a container makes a risk assessment of Pneumonia for incoming images.
+A Grafana dashboard displays the pipeline in real time, along with images incoming, processed, anonymized, and full metrics collected from Prometheus.
+The simplified pipeline without Intel AMX is showcased in this video.
+About the solution elements The solution aids the understanding of the following:
+How to use a GitOps approach to keep in control of configuration and operations.
+How to deploy AI/ML technologies for medical diagnosis using GitOps.
+The Medical Diagnosis pattern uses the following products and technologies:
+Red Hat OpenShift Container Platform for container orchestration
+Red Hat OpenShift GitOps, a GitOps continuous delivery (CD) solution
+Red Hat AMQ, an event streaming platform based on the Apache Kafka
+Red Hat OpenShift Serverless for event-driven applications
+Red Hat OpenShift Data Foundation for cloud native storage capabilities
+Grafana Operator to manage and share Grafana dashboards, data sources, and so on
+Node Feature Discovery Operator to label nodes with Intel AMX capabilities
+About the architecture Presently, the Intel AMX accelerated Medical Diagnosis pattern does not have an edge component. Edge deployment capabilities are planned as part of the pattern architecture for a future release.
+Components are running on OpenShift either at the data center, at the medical facility, or public cloud running OpenShift.
+The diagram below shows the components that are deployed with the the data flows and API calls between them.
+Next steps Getting started Deploy the Pattern
+`,url:"https://validatedpatterns.io/patterns/medical-diagnosis-amx/",breadcrumb:"/patterns/medical-diagnosis-amx/"},"https://validatedpatterns.io/patterns/multicloud-gitops-amx/":{title:"Intel AMX accelerated Multicloud GitOps",tags:[],content:` About the Intel AMX accelerated Multicloud GitOps pattern Use case Use a GitOps approach to manage hybrid and multi-cloud deployments across both public and private clouds.
+Enable cross-cluster governance and application lifecycle management.
+Accelerate AI operations and improve computational performance by using Intel Advanced Matrix Extensions.
+Securely manage secrets across the deployment.
+Based on the requirements of a specific implementation, certain details might differ. However, all validated patterns that are based on a portfolio architecture, generalize one or more successful deployments of a use case.
+Background Organizations are aiming to develop, deploy, and operate applications on an open hybrid cloud in a stable, simple, and secure way. This hybrid strategy includes multi-cloud deployments where workloads might be running on multiple clusters and on multiple clouds, private or public. This strategy requires an infrastructure-as-code approach: GitOps. GitOps uses Git repositories as a single source of truth to deliver infrastructure-as-code. Submitted code checks the continuous integration (CI) process, while the continuous delivery (CD) process checks and applies requirements for things like security, infrastructure-as-code, or any other boundaries set for the application framework. All changes to code are tracked, making updates easy while also providing version control should a rollback be needed. Moreover, organizations are looking for solutions that increase efficiency and at the same time reduce costs, what is possible using 5th Generation Intel Xeon Scalable Processors with a new build-in accelerator - Intel Advanced Matrix Extensions.
+About the solution This architecture covers hybrid and multi-cloud management with GitOps as shown in following figure. At a high level this requires a management hub, for DevOps and GitOps, and infrastructure that extends to one or more managed clusters running on private or public clouds. The automated infrastructure-as-code approach can manage the versioning of components and deploy according to the infrastructure-as-code configuration.
+Benefits of Hybrid Multicloud management with GitOps:
+Unify management across cloud environments.
+Dynamic infrastructure security.
+Infrastructural continuous delivery best practices.
+Figure 1. Overview of the solution including the business drivers, management hub, and the clusters under management In the following figure, logically, this solution can be viewed as being composed of an automation component, unified management including secrets management, and the clusters under management, all running on top of a user-chosen mixture of on-premise data centers and public clouds.
+Figure 2. Logical diagram of Intel AMX accelerated hybrid multi-cloud management with GitOps About the technology The following technologies are used in this solution:
+Red Hat OpenShift Platform An enterprise-ready Kubernetes container platform built for an open hybrid cloud strategy. It provides a consistent application platform to manage hybrid cloud, public cloud, and edge deployments. It delivers a complete application platform for both traditional and cloud-native applications, allowing them to run anywhere. OpenShift has a pre-configured, pre-installed, and self-updating monitoring stack that provides monitoring for core platform components. It also enables the use of external secret management systems, for example, HashiCorp Vault in this case, to securely add secrets into the OpenShift platform.
+Red Hat OpenShift GitOps A declarative application continuous delivery tool for Kubernetes based on the ArgoCD project. Application definitions, configurations, and environments are declarative and version controlled in Git. It can automatically push the desired application state into a cluster, quickly find out if the application state is in sync with the desired state, and manage applications in multi-cluster environments.
+Red Hat Advanced Cluster Management for Kubernetes Controls clusters and applications from a single console, with built-in security policies. Extends the value of Red Hat OpenShift by deploying apps, managing multiple clusters, and enforcing policies across multiple clusters at scale.
+Red Hat Ansible Automation Platform Provides an enterprise framework for building and operating IT automation at scale across hybrid clouds including edge deployments. It enables users across an organization to create, share, and manage automation, from development and operations to security and network teams.
+Node Feature Discovery Operator Manages the detection of hardware features and configuration in an OpenShift Container Platform cluster by labeling the nodes with hardware-specific information. NFD labels the host with node-specific attributes, such as PCI cards, kernel, operating system version, and so on.
+Intel® Advanced Matrix Extensions A new built-in accelerator that improves the performance of deep-learning training and inference on the CPU and is ideal for workloads like natural-language processing, recommendation systems and image recognition.
+Hashicorp Vault Provides a secure centralized store for dynamic infrastructure and applications across clusters, including over low-trust networks between clouds and data centers.
+This solution also uses a variety of observability tools including the Prometheus monitoring and Grafana dashboard that are integrated with OpenShift as well as components of the Observatorium meta-project which includes Thanos and the Loki API.
+Overview of the architectures The following figure provides a schematic diagram overview of the complete solution including both components and data flows.
+Figure 3. Overview schematic diagram of the complete solution Subsequent schematic diagrams provide details on:
+Bootstrapping the management hub (Figure 4)
+Hybrid multi-cloud GitOps (Figure 5)
+Dynamic security management (Figure 6)
+Bootstrapping the management hub The following figure provides a schematic diagram showing the setup of the management hub using Ansible playbooks.
+Figure 4. Schematic diagram of bootstrapping the management hub Set up the OpenShift Container Platform that hosts the Management Hub. The OpenShift installation program provides flexible ways to install OpenShift. An Ansible playbook starts the installation with necessary configurations.
+Ansible playbooks deploy and configure Red Hat Advanced Cluster Management for Kubernetes and, later, other supporting components such as external secrets management, on top of the provisioned OpenShift cluster.
+Another Ansible playbook installs HashiCorp Vault, a Red Hat partner product chosen for this solution that can be used to manage secrets for OpenShift clusters.
+An Ansible playbook configures and installs the Openshift GitOps operator on the hub cluster. This deploys the Openshift GitOps instance to enable continuous delivery.
+Hybrid Multicloud GitOps The following figure provides a schematic diagram showing remaining activities associated with setting up the management hub and clusters using Red Hat Advanced Cluster Management.
+Figure 5. Schematic diagram of hybrid multi-cloud management with GitOps Manifest and configuration are set as code template in the form of a Kustomization YAML file. The file describes the desired end state of the managed cluster. When complete, the Kustomization YAML file is pushed into the source control management repository with a version assigned to each update.
+OpenShift GitOps monitors the repository and detects changes in the repository.
+OpenShift GitOps creates and updates the manifest by creating Kubernetes objects on top of Red Hat Advanced Cluster Management.
+Red Hat Advanced Cluster Management provisions, updates, or deletes managed clusters and configuration according to the manifest. In the manifest, you can configure what cloud provider the cluster will be on, the name of the cluster, infrastructure node details and worker node. Governance policy can also be applied as well as provision an agent in the cluster as the bridge between the control center and the managed cluster.
+OpenShift GitOps continuously monitors the code repository and the status of the clusters reported back to Red Hat Advanced Cluster Management. Any configuration drift or in case of any failure, OpenShift GitOps will automatically try to remediate by applying the manifest or by displaying alerts for manual intervention.
+Dynamic security management The following figure provides a schematic diagram showing how secrets are handled in this solution.
+Figure 6. Schematic showing the setup and use of external secrets management During setup, the token to securely access HashiCorp Vault is stored in Ansible Vault. It is encrypted to protect sensitive content.
+Red Hat Advanced Cluster Management for Kubernetes acquires the token from Ansible Vault during install and distributes it among the clusters. As a result, you have centralized control over the managed clusters through RHACM.
+To allow the cluster access to the external vault, you must set up the external secret management with Helm in this study. OpenShift Gitops is used to deploy the external secret object to a managed cluster.
+External secret management fetches secrets from HashiCorp Vault by using the token that was generated in step 2 and constantly monitors for updates.
+Secrets are created in each namespace, where applications can use them.
+Additional resources View and download all of the diagrams above from the Red Hat Portfolio Architecture open source tooling site.
+Intel AMX accelerated Multicloud GitOps pattern The basic Multicloud GitOps pattern has been extended to highlight the 5th Generation Intel Xeon Scalable Processors capabilities, offering developers a streamlined pathway to accelerate their workloads through the integration of cutting-edge Intel AMX, fostering efficiency and performance optimization in AI workloads.
+The basic pattern has been extended by the AI application named amx-app. It runs Deep Interest Evolution Network (DIEN) inference using the Intel-optimized TensorFlow and measures its accuracy. DIEN is a machine learning model used in the field of recommender systems, particularly in the domain of personalized content recommendation.
+Since the amx-app application must be running on the node with CPU supporting Intel AMX, Node Feature Discovery Operator (NFD) is deployed as a part of this pattern. NFD manages the detection of hardware features and configuration in an OpenShift Container Platform cluster. It labels the nodes with hardware-specific information. The kernel detects Intel AMX at run-time, so there is no need to enable and configure it separately.
+A deployment of amx-app was created based on instructions from Model Zoo for Intel® Architecture repository - TF DIEN inference and uses intel/recommendation:tf-spr-dien-inference image.
+An amx-app use persistent volume claim to download and prepare dataset. When the dataset is ready, an application runs and measures the inference accuracy. By enabling ONEDNN verbose all the compiled instructions are shown in the logs. The appearance of the avx512_core_amx_bf16 flag confirms that Intel AMX is used.
+Figure 7. Logs from amx-app pod Next steps Deploy the management hub using Helm.
+Add a managed cluster to deploy the managed cluster piece using ACM.
+`,url:"https://validatedpatterns.io/patterns/multicloud-gitops-amx/",breadcrumb:"/patterns/multicloud-gitops-amx/"},"https://validatedpatterns.io/patterns/multicloud-gitops-qat/":{title:"Intel QAT accelerated Multicloud GitOps",tags:[],content:` About the Intel QAT accelerated Multicloud GitOps pattern Use case Use a GitOps approach to manage hybrid and multi-cloud deployments across both public and private clouds.
+Enable cross-cluster governance and application lifecycle management.
+Accelerate TLS handshaking operations and improve computational performance by offloading cryptographic tasks to QAT.
+Securely manage secrets across the deployment.
+Simplify managing different microservices that make up a cloud-native application with Istio service mesh.
+Based on the requirements of a specific implementation, certain details might differ. However, all validated patterns that are based on a portfolio architecture, generalize one or more successful deployments of a use case.
+Background Organizations are aiming to develop, deploy, and operate applications on an open hybrid cloud in a stable, simple, and secure way. This hybrid strategy includes multi-cloud deployments where workloads might be running on multiple clusters and on multiple clouds, private or public. This strategy requires an infrastructure-as-code approach: GitOps. GitOps uses Git repositories as a single source of truth to deliver infrastructure-as-code. Submitted code checks the continuous integration (CI) process, while the continuous delivery (CD) process checks and applies requirements for things like security, infrastructure-as-code, or any other boundaries set for the application framework. All changes to code are tracked, making updates easy while also providing version control should a rollback be needed. Moreover, organizations which are looking to deliver distributed applications at scale can make these applications faster by offloading cryptographic tasks to Intel QuickAssist Technology.
+About the solution This architecture covers hybrid and multi-cloud management with GitOps as shown in following figure. At a high level this requires a management hub, for DevOps and GitOps, and infrastructure that extends to one or more managed clusters running on private or public clouds. The automated infrastructure-as-code approach can manage the versioning of components and deploy according to the infrastructure-as-code configuration.
+Benefits of Hybrid Multicloud management with GitOps:
+Unify management across cloud environments.
+Dynamic infrastructure security.
+Infrastructural continuous delivery best practices.
+Figure 1. Overview of the solution including the business drivers, management hub, and the clusters under management In the following figure, logically, this solution can be viewed as being composed of an automation component, unified management including secrets management, and the clusters under management, all running on top of a user-chosen mixture of on-premise data centers and public clouds.
+Figure 2. Logical diagram of Intel QAT accelerated hybrid multi-cloud management with GitOps About the technology The following technologies are used in this solution:
+Red Hat OpenShift Platform An enterprise-ready Kubernetes container platform built for an open hybrid cloud strategy. It provides a consistent application platform to manage hybrid cloud, public cloud, and edge deployments. It delivers a complete application platform for both traditional and cloud-native applications, allowing them to run anywhere. OpenShift has a pre-configured, pre-installed, and self-updating monitoring stack that provides monitoring for core platform components. It also enables the use of external secret management systems, for example, HashiCorp Vault in this case, to securely add secrets into the OpenShift platform.
+Red Hat OpenShift GitOps A declarative application continuous delivery tool for Kubernetes based on the ArgoCD project. Application definitions, configurations, and environments are declarative and version controlled in Git. It can automatically push the desired application state into a cluster, quickly find out if the application state is in sync with the desired state, and manage applications in multi-cluster environments.
+Red Hat Advanced Cluster Management for Kubernetes Controls clusters and applications from a single console, with built-in security policies. Extends the value of Red Hat OpenShift by deploying apps, managing multiple clusters, and enforcing policies across multiple clusters at scale.
+Red Hat Ansible Automation Platform Provides an enterprise framework for building and operating IT automation at scale across hybrid clouds including edge deployments. It enables users across an organization to create, share, and manage automation, from development and operations to security and network teams.
+Node Feature Discovery Operator Manages the detection of hardware features and configuration in an OpenShift Container Platform cluster by labeling the nodes with hardware-specific information. NFD labels the host with node-specific attributes, such as PCI cards, kernel, operating system version, and so on.
+Intel® QuickAssist Technology Accelerate data encryption and compression for applications from networking to enterprise, cloud to storage, and content delivery to database with Intel® QuickAssist Technology.
+Intel® Device Plugin Operator The Intel Technology Enabling for OpenShift project provides Intel Data Center hardware feature-provisioning technologies with the Red Hat OpenShift Container Platform (RHOCP).
+Sail Operator, Istio Operator for Red Hat OpenShift A service mesh is a dedicated infrastructure layer that you can add to your applications. It allows you to transparently add capabilities like observability, traffic management, and security, without adding them to your code. Sail Operator serves as the foundation for Red Hat OpenShift Service Mesh 3.
+Hashicorp Vault Provides a secure centralized store for dynamic infrastructure and applications across clusters, including over low-trust networks between clouds and data centers.
+This solution also uses a variety of observability tools including the Prometheus monitoring and Grafana dashboard that are integrated with OpenShift as well as components of the Observatorium meta-project which includes Thanos and the Loki API.
+Overview of the architectures The following figure provides a schematic diagram overview of the complete solution including both components and data flows.
+Figure 3. Overview schematic diagram of the complete solution Subsequent schematic diagrams provide details on:
+Bootstrapping the management hub (Figure 4)
+Hybrid multi-cloud GitOps (Figure 5)
+Dynamic security management (Figure 6)
+Bootstrapping the management hub The following figure provides a schematic diagram showing the setup of the management hub using Ansible playbooks.
+Figure 4. Schematic diagram of bootstrapping the management hub Set up the OpenShift Container Platform that hosts the Management Hub. The OpenShift installation program provides flexible ways to install OpenShift. An Ansible playbook starts the installation with necessary configurations.
+Ansible playbooks deploy and configure Red Hat Advanced Cluster Management for Kubernetes and, later, other supporting components such as external secrets management, on top of the provisioned OpenShift cluster.
+Another Ansible playbook installs HashiCorp Vault, a Red Hat partner product chosen for this solution that can be used to manage secrets for OpenShift clusters.
+An Ansible playbook configures and installs the Openshift GitOps operator on the hub cluster. This deploys the Openshift GitOps instance to enable continuous delivery.
+Hybrid Multicloud GitOps The following figure provides a schematic diagram showing remaining activities associated with setting up the management hub and clusters using Red Hat Advanced Cluster Management.
+Figure 5. Schematic diagram of hybrid multi-cloud management with GitOps Manifest and configuration are set as code template in the form of a Kustomization YAML file. The file describes the desired end state of the managed cluster. When complete, the Kustomization YAML file is pushed into the source control management repository with a version assigned to each update.
+OpenShift GitOps monitors the repository and detects changes in the repository.
+OpenShift GitOps creates and updates the manifest by creating Kubernetes objects on top of Red Hat Advanced Cluster Management.
+Red Hat Advanced Cluster Management provisions, updates, or deletes managed clusters and configuration according to the manifest. In the manifest, you can configure what cloud provider the cluster will be on, the name of the cluster, infrastructure node details and worker node. Governance policy can also be applied as well as provision an agent in the cluster as the bridge between the control center and the managed cluster.
+OpenShift GitOps continuously monitors the code repository and the status of the clusters reported back to Red Hat Advanced Cluster Management. Any configuration drift or in case of any failure, OpenShift GitOps will automatically try to remediate by applying the manifest or by displaying alerts for manual intervention.
+Dynamic security management The following figure provides a schematic diagram showing how secrets are handled in this solution.
+Figure 6. Schematic showing the setup and use of external secrets management During setup, the token to securely access HashiCorp Vault is stored in Ansible Vault. It is encrypted to protect sensitive content.
+Red Hat Advanced Cluster Management for Kubernetes acquires the token from Ansible Vault during install and distributes it among the clusters. As a result, you have centralized control over the managed clusters through RHACM.
+To allow the cluster access to the external vault, you must set up the external secret management with Helm in this study. OpenShift Gitops is used to deploy the external secret object to a managed cluster.
+External secret management fetches secrets from HashiCorp Vault by using the token that was generated in step 2 and constantly monitors for updates.
+Secrets are created in each namespace, where applications can use them.
+Additional resources View and download all of the diagrams above from the Red Hat Portfolio Architecture open source tooling site.
+Intel QAT accelerated Multicloud GitOps pattern The basic Multicloud GitOps pattern has been extended to highlight the 5th Generation Intel Xeon Scalable Processors capabilities, offering developers a streamlined pathway to accelerate their workloads through the integration of Intel QAT.
+The basic pattern has been extended by 4 components: Intel Device Plugin Operator, Node Feature Discovery Operator (NFD), Sail Operator, and simple HTTP request and response application. The main purpose of this extension is to enable TLS handshaking and showcase how Intel QAT accelerates cryptographic operations.
+Intel Device Plugin Operator’s task is to expose QAT resources to the Openshift layer, so it makes it easy to use when creating deployments. After QAT resources are properly exposed Node Feature Discovery Operator is deployed. NFD manages the detection of hardware features and configuration in an OpenShift Container Platform cluster. It labels the nodes with hardware-specific information.
+Sail Operator deploys Istio Service Mesh. It is basically an extra layer added on top of user applications, and it adds capabilities like traffic management between services and security, without manually adding them to code. The Istio version deployed by Sail Operator allows for additional configuration, that is enabling Intel QAT in cryptographic operations. The last added component is the httpbin application, which is HTTP request and response service used for testing and showcase purposes. The workload idea was based on Istio’s official instructions on how to setup secure TLS ingress gateway.
+The appearance of qat as a private key provider in Istio ingress gateway pod logs confirms that Intel QAT is used:
+Figure 7. Logs from Istio ingress gateway pod Next steps Deploy the management hub using Helm.
+Add a managed cluster to deploy the managed cluster piece using ACM.
+`,url:"https://validatedpatterns.io/patterns/multicloud-gitops-qat/",breadcrumb:"/patterns/multicloud-gitops-qat/"},"https://validatedpatterns.io/patterns/emerging-disease-detection/":{title:"Emerging Disease Detection",tags:[],content:` About the Emerging Disease Detection pattern Use case Use a GitOps approach to manage a hybrid cloud deployment for an AI emerging disease detection system.
+Use a AI automation at the edge to detect emerging diseases.
+Use an event driven architecture
+Enable application lifecycle management.
+Securely manage secrets across the deployment.
+Background No technology is better poised to transform Healthcare as AI and Business Process Automation. Coupled with an Edge Architecture, these continuous monitoring and detection systems can scale to provide early warning intervention and measurable process improvements, anywhere.
+Detection of disease states like sepsis, stroke, pulmonary embolism, and heart attack requires low-latency, broadband, asynchronous streaming capabilities. We have prototyped an early warning platform built with a distributed edge architecture, fed by at-home post-operative monitoring (fitbit, smart phone, wifi devices) and automated Clinical care escalation and coordination processes. This platform has the potential to significantly lower network traffic and cost while providing early warning interventions for our nation’s Veterans.
+About the solution To demonstrate the effectiveness of the solution this pattern focuses on the specific problem of Sepsis. Sepsis is the body’s extreme response to an infection. It is a life-threatening medical emergency. Sepsis is a costly and life threatening condition that can result in multi-organ failure. Beating conditions like sepsis requires rapid detection and mitigation of risks. With the immune system compromised, recovery at home is often preferred to minimize the risk for cross-infections, yet medical teams often lack the capability to perform constant surveillance for emerging risks across their patient cohorts, especially in rural settings. In this session, we will demonstrate an early warning system driven by Clinical AI at the Edge, fed by at-home post-operative monitoring and automated Clinical care escalation and coordination processes.
+Technology Highlights: Event-Driven Architecture
+Red Hat OpenShift Data Science
+Process Automation
+Solution Discussion and Demonstration In this demonstration, we will follow a vulnerable, post-operative patient, Alani, as she recovers from surgery in her home setting. The pattern demonstrates an early warning system driven by Clinical AI at the Edge, fed by at-home post-operative monitoring and automated Clinical care escalation and coordination processes.
+This architecture pattern demonstrates three strengths:
+Enabling healthcare at the edge
+Taking healthcare past the edge of the cloud to support care processes in Low Bandwidth environments.
+AI integrated into healthcare team workflows
+BPM+ Health workflows support plug &amp; play AI modules embedded into clinical workflows as Clinical Decision Support.
+Event driven, Intelligent automation
+Clinical best practices &amp; processes automated using BPM+ Health authored workflows using FHIR API endpoints.
+For a thorough explanation of this solution in the context of Sepsis detection please consider reviewing the following 25 minute video.
+Overview of the solution in Sepsis Detection Overview of the Architecture As data arrives from Alani’s various monitoring devices her latest metrics are collected in the FHIR database. Debezium is an open source distributed platform for change data capture. It will create an observation bundle for streaming to the AI model. This, in turn, will create a risk assessment and provide that to the process automation for review with Alani’s doctor or the on-call doctor that is available. Their assessment may trigger further process workflows.
+Figure 1. Overview of the solution reference architecture In the following figure, logically, this solution can be viewed as being composed of an automation component, unified management including secrets management, and the clusters under management, all running on top of a user-chosen mixture of on-premise data centers and public clouds.
+Figure 2. Sepsis Data Architecture Figure 3. Logical Architecture Figure 4. Data Flow Architecture About the technology The following technologies are used in this solution:
+Red Hat OpenShift Platform An enterprise-ready Kubernetes container platform built for an open hybrid cloud strategy. It provides a consistent application platform to manage hybrid cloud, public cloud, and edge deployments. It delivers a complete application platform for both traditional and cloud-native applications, allowing them to run anywhere. OpenShift has a pre-configured, pre-installed, and self-updating monitoring stack that provides monitoring for core platform components. It also enables the use of external secret management systems, for example, HashiCorp Vault in this case, to securely add secrets into the OpenShift platform.
+Red Hat OpenShift GitOps A declarative application continuous delivery tool for Kubernetes based on the ArgoCD project. Application definitions, configurations, and environments are declarative and version controlled in Git. It can automatically push the desired application state into a cluster, quickly find out if the application state is in sync with the desired state, and manage applications in multi-cluster environments.
+Red Hat Ansible Automation Platform Provides an enterprise framework for building and operating IT automation at scale across hybrid clouds including edge deployments. It enables users across an organization to create, share, and manage automation, from development and operations to security and network teams.
+Red Hat AMQ Streams Red Hat AMQ streams is a massively scalable, distributed, and high-performance data streaming platform based on the Apache Kafka project. It offers a distributed backbone that allows microservices and other applications to share data with high throughput and low latency. Red Hat AMQ Streams is available in the Red Hat AMQ product.
+Red Hat Single Sign-On Based on the Keycloak project, Red Hat Single Sign-On enhances security by enabling you to secure your web applications with Web single sign-on (SSO) capabilities based on popular standards such as SAML 2.0, OpenID Connect and OAuth 2.0.
+Hashicorp Vault Provides a secure centralized store for dynamic infrastructure and applications across clusters, including over low-trust networks between clouds and data centers.
+This solution also uses a variety of observability tools including the Prometheus monitoring and Grafana dashboard that are integrated with OpenShift as well as components of the Observatorium meta-project which includes Thanos and the Loki API.
+Next steps Deploy the management hub using Helm.
+`,url:"https://validatedpatterns.io/patterns/emerging-disease-detection/",breadcrumb:"/patterns/emerging-disease-detection/"},"https://validatedpatterns.io/patterns/retail/":{title:"Retail",tags:[],content:`Retail Pattern Background This pattern demonstrates a pattern that models the store side of a retail application.
+It is derived from the Quarkus Coffeeshop Demo done by Red Hat Solution Architects. The demo models the use of multiple application microservices which use Kafka messaging to interact and a Postgres database to persist data. (There is a homeoffice analytics suite in the demo that we hope to include in a later version of the pattern.
+This demo pulls together several different strands of the demo and allows for multiple stores to be installed on remote clusters via ACM if the user desires.
+The demo allows users to go to the store&rsquo;s web page, order drinks and food items, and see those items &ldquo;made&rdquo; and served by the microservices in real time.
+The pattern includes build pipelines and a demo space, so that changes to the applications can be tested prior to &ldquo;production&rdquo; deployments.
+Solution elements How to use a GitOps approach to keep in control of configuration and operations How to centrally manage multiple clusters, including workloads How to build and deploy workloads across clusters using modern CI/CD How to architect a modern application using microservices and Kafka in Java Red Hat Technologies Red Hat OpenShift Container Platform (Kubernetes) Red Hat Advanced Cluster Management (Open Cluster Management) Red Hat OpenShift GitOps (ArgoCD) Red Hat OpenShift Pipelines (Tekton) Red Hat AMQ Streams (Apache Kafka Event Broker) Architecture The following diagram shows the relationship between the microservices, messaging, and database components:
+The hub. This cluster hosts the CI/CD pipelines, a test instance of the applications and messaging/database services for testing purposes, and a single functional store. Optional remote clusters. Each remote site can support a complete store environment. The default one modelled is a &ldquo;RALEIGH&rdquo; store location. Demo Scenario The Retail Validated Pattern / Demo Scenario is focused in the Quarkus Coffeeshop retail experience. In a full retail environment, it would be easy to be overwhelmed by things like item files, tax tables, item movement/placement within the store and so on, so the demo does not attempt to model all those elements - instead offering a subset of services to give a sense of how data can flow in such a system, how microservices should interact (via API calls and message passing), and where data can be persisted.
+In the future we hope to expand this pattern with the homeoffice components, to further demonstrate how data can flow from leaf nodes to centralized data analytics services, which are crucial in retail IT environments.
+Web Service - the point of sale within the store. Shows the menu, and allows the user to order food and drinks, and shows when orders are ready. Counter service - the &ldquo;heart&rdquo; of the store operation - receives orders and dispatches them to the barista and kitchen services, as appropriate. Users may order as many food and drink items in one order as they wish. Barista - the service responsible for providing items from the &ldquo;drinks&rdquo; side of the menu. Kitchen - the service responsible for providing items from the &ldquo;food&rdquo; side of the menu. Further documentation on the individual services is available at the upstream Quarkus Coffeeshop documentation site.
+`,url:"https://validatedpatterns.io/patterns/retail/",breadcrumb:"/patterns/retail/"},"https://validatedpatterns.io/blog/2022-12-01-multicluster-devsecops/":{title:"Multicluster DevSecOps",tags:[],content:`Multicluster DevSecOps Software supply chain security: The why and what Today more and more organizations are turning to agile development models and DevOps. With this approach, development organizations can deliver more enhancements and bug fixes in a timely manner, providing more value to their customers. While DevOps can include security earlier in the software lifecycle, in practice this has not always been the case. DevSecOps explicitly calls on organizations to pay attention to security best practices and to automate them or “Shift Left” as much as possible.
+DevSecOps means baking in application and infrastructure security from the start. In order to be successful, organizations must look both upstream where their dependencies come from, and also how their components integrate together in the production environment. It also means automating security gates to keep the DevOps workflow from slowing down. As we learn from experience, we codify that into the automation process.
+A successful DevSecOps based supply chain must consider four areas of concern:
+Secure developer dependencies Secure code development Secure deployment of resources into a secure environment Software Bill of Materials (SBOM) Within each of these areas there are also many best practices to be applied particularly in Cloud Native development using container technology.
+Scanning new development code for potential vulnerabilities Scanning dependent images that new code will be layered upon Attesting to the veracity of images using image signing Scanning images for know CVEs Scanning the environment for potential networking vulnerabilities Scanning for misconfiguration of images and other assets Ensuring consistent automated deployment of secure configuration using GitOps Continuous upgrading of security policies from both trusted third parties and experience This pattern deploys several Red Hat Products:
+Red Hat OpenShift Container Platform (Kubernetes platform) Red Hat OpenShift GitOps (ArgoCD) Red Hat Advanced Cluster Management (Open Cluster Management) Red Hat OpenShift Pipelines (Tekton) Red Hat Quay (OCI image registry with security features enabled) Red Hat Open Data Foundation (highly available storage) Red Hat Advanced Cluster Security (scanning and monitoring) Highlight: Multicluster While all of the components can be deployed on a single cluster, which makes for a simple demo, this pattern deploys a real world architecture where the central management, development environments, and production are all deployed on different clusters. This ensures that the pattern is structured for real-world deployments, with all the functionality needed to make such an architecture work already built-in, so that pattern consumers can concentrate on what is being delivered, rather than how.
+The heavy lifting in the pattern includes a great deal of integration between components, especially those spanning across clusters:
+Deployment of Quay Enterprise with OpenShift Data Foundations as a storage backend Deployment of Quay Bridge operator configured to connect with Quay Enterprise on hub cluster Deployment of ACS on managed nodes with integration back to ACS central on the hub Deployment of a secure pipeline with scanning and signing tools, including ACS Highlight: DevSecOps with Pipelines &ldquo;OpenShift Pipelines makes CI/CD concepts such as a &lsquo;pipeline&rsquo;, a &rsquo;task&rsquo;, a &lsquo;step&rsquo; natively instantiatable [sic] so it can use the scalability, security, ease of deployment capabilities of Kubernetes.&rdquo; (Introducing OpenShift Pipelines). The pattern consumes many of the OpenShift Pipelines out of the box tasks but also defines new tasks for scanning and signing and includes them in enhanced DevSecOps pipelines.
+While these pipelines are included in the pattern, the pattern also implements the use of Pipelines-as-Code feature where the pipeline can be part of the application code repository. &ldquo;This allows developers to ship their CI/CD pipelines within the same git repository as their application, making it easier to keep both of them in sync in terms of release updates.&rdquo;
+Highlight: Using the CI Pipeline to provide supply chain security This pattern includes some other technologies in the development CI pipeline, including cosign, a SIGSTORE project, implemented with Tekton Chains. Cosign supports container signing, verification, and storage in an OCI registry. It enables consumers to sign their pipeline resources and images and share the attestation files providing downstream consumers assurances that they are consuming a trusted artifact.
+We also implement open source tools like Sonarqube for static code analysis, nexus for securely storing build artifacts in-cluster, and an open source reports application that is used to upload and present the reports from the security pipeline.
+Not using these tools in your environment? That’s not a problem. The pattern framework is flexible. Organizations using different services can swap out what’s in the pattern with their software of choice to fit their environment.
+Where do we go from here? This pattern provides a complete deployment solution for Multicluster DevSecOps that can be used as part of a supply chain deployment pattern across different industries.
+Documentation for how to install the pattern is here, where there are detailed installation instructions and more technical details on the different components in the pattern.
+`,url:"https://validatedpatterns.io/blog/2022-12-01-multicluster-devsecops/",breadcrumb:"/blog/2022-12-01-multicluster-devsecops/"},"https://validatedpatterns.io/blog/2022-11-20-argo-rollouts/":{title:"Progressive Delivery with Argo Rollouts",tags:[],content:`Progressive Delivery with Argo Rollouts Introduction Progressive delivery is about the controlled deployment of an application. It is by no means a new concept when it comes to software deployment and delivery. The concept (maybe not in name) has been around for quite a while, and if you’ve done application or system updates prior to kubernetes some of these concepts will sound familiar. The rollout resource is a direct replacement of the kubernetes deployment resource. This allows for very easy conversion of an existing deployment into a rollout resource.
+Additionally, Argo Rollouts can use metrics from a number of providers (we&rsquo;ll be using the default - prometheus) which can be used to abort a rollout if there are issues with the application deployment such as failed health checks, pod restarts ..etc. Using metrics to control the rollout is beyond the scope of this blog, but will be part of a future blog.
+OpenShift and OpenShift-GitOps do not officially support argo-rollouts to date, but support should be expected in 2023
+Blue/Green is the concept of having two versions of the same application running at the same time so that we can verify that the application updates are behaving the way they are supposed to. The blue (or production) application doesn’t change at all and the green (preview/updated application) is deployed beside it. While this is a tried and true approach it does have some drawbacks. One significant drawback to this strategy is that you will need to have enough capacity to support both applications running simultaneously. This can be a major hurdle in resource-constrained environments, or with applications that require a license to operate.
+Credits: argoproj.github.io
+Canary is the more modern, more advanced approach to blue/green. With a canary deployment we deploy the new version of the application to a subset of our users, while the rest will continue with the original version. If there’s an issue with the new version, only that subset of users will be affected. With canary rollouts we can specify the percentage of traffic that gets allocated to the new application release as well as a timer for how long we want in between steps. This is ideal when you are trying to test a new feature and you want to gather metrics / data from live traffic.
+Credits: argoproj.github.io
+In this blog, we’re going to use OpenShift Gitops to deploy the Argo Rollouts progressive delivery controller and we’re going to walk through a blue/green deployment as well as a canary deployment.
+Preparation Let’s start by deploying the argo-rollouts pattern from the argo-rollouts. For this demo, I have deployed a 3-Node compact cluster using m5.2xlarge machine types in AWS. This demo will only use rollouts to deploy onto a single cluster.
+oc get nodes NAME STATUS ROLES AGE VERSION ip-10-0-137-28.us-east-2.compute.internal Ready master,worker 13h v1.24.6+5157800 ip-10-0-165-204.us-east-2.compute.internal Ready master,worker 13h v1.24.6+5157800 ip-10-0-206-142.us-east-2.compute.internal Ready master,worker 13h v1.24.6+5157800 oc get machines -n openshift-machine-api NAME PHASE TYPE REGION ZONE AGE argo-rollouts-7d9dd-master-0 Running m5.2xlarge us-east-2 us-east-2a 13h argo-rollouts-7d9dd-master-1 Running m5.2xlarge us-east-2 us-east-2b 13h argo-rollouts-7d9dd-master-2 Running m5.2xlarge us-east-2 us-east-2c 13h If you&rsquo;ve never deployed OpenShift before, you could try ROSA the pay-as-you-go OpenShift managed service.
+Next, you&rsquo;ll need to create a fork of the argo-rollouts repo. Go there in a browser, make sure you’re logged in to GitHub, click the “Fork” button, and confirm the destination by clicking the big green &ldquo;Create fork&rdquo; button.
+Next, install the Validated Patterns operator from Operator Hub.
+And finally, click through to the installed operator, and select the Create instance button and fill out the Create a Pattern form. Most of the defaults are fine, but make sure you update the GitSpec URL to point to your fork of argo-rollouts, rather than https://github.com/hybrid-cloud-patterns/argo-rollouts.
+To see what’s going on, click on “Installed Operators” and then change the Project to “All Projects”. After a bit, you will see the following operators installed: Advanced Cluster Manager for Kubernetes multicluster engine for kubernetes Red Hat OpenShift GitOps Package Server Validated Patterns Operator
+Once everything is installed we need to clone our fork of the repository to our local machine. Go to your account in github and click the big green “code” button, and then click the “copy” icon to copy the url of the repository.
+Switch over to your cli and type: git clone &lt;paste_the_url_just_copied&gt; ; next, change directories into the repository.
+Optionally, the argo project provides a plugin for the kubectl which can be used to manage rollouts in our cluster. This is totally optional and not required, however it does make it easy to track progress of the rollout. To install follow the official install procedures.
+Argo Rollouts In your copy of the repository, we can find the manifests that make up argo rollouts in charts/all/argo-rollouts/templates. Now we COULD use oc/kubectl create -f but that defeats the purpose of gitops! So we&rsquo;re going to use openshift-gitops and the validated pattern framework to deploy the argo rollouts controller for us.
+If you are interested in understanding what each of the manifests are for, I encourage you to visit the argo rollouts architecture page which details each resource.
+Let&rsquo;s review how the framework is deploying argo-rollouts for us. Take a look at values-hub.yaml to see how argo rollouts is declared:
+First, we tell argocd to create the argo-rollouts namespace
+namespaces: - open-cluster-management - vault - golang-external-secrets - argo-rollouts Next, we define a project, a project is an argocd resource that groups application resources together
+projects: - hub - argo-rollouts Finally, we add a map for argo-rollouts where we define our application
+applications: &lt;...omitted...&gt; argo-rollouts: name: argo-rollouts namespace: argo-rollouts project: argo-rollouts path: charts/all/argo-rollouts To watch the deployment in action, log in to your cluster console, and then select the “squared” drop down box and select “Hub ArgoCD”. After accepting the security warnings for self-signed certificates, in the ArgoCD login screen click “Login with OpenShift”, when prompted select “Allow user permissions”.
+You are now in the ArgoCD console and can see the applications deployed (or being deployed). If you don’t see the rollouts application right away don’t fret, by default, ArgoCD’s reconciliation loop runs every 3 minutes.
+After a few, you should see the following in your ArgoCD console.
+With Argo Rollouts deployed, we can start using progressive delivery! Let’s start with blue/green!
+Blue/Green When you use a blue/green deployment strategy you will have two instances of the application running simultaneously. The “blue” or production instance will continue to receive connections and run without change, the “green” or updated application will start and be available using a different service. You can create a route (or ingress) if you’d like, and then when satisfied promote the “green” application to production.
+Once promoted the rollout will update the &ldquo;blue&rdquo; replicaset which will then scale the &ldquo;blue&rdquo; version of the pods down to zero. After the rollout promotion is completed we can check the rollout status using the argo rollouts plugin.
+Let&rsquo;s add the bluegreen application to our pattern. The first thing we need to do is update the values-hub.yaml file.
+Add bluegreen namespace to the list of namespaces to be created by openshift-gitops namespaces: - open-cluster-management - vault - golang-external-secrets - argo-rollouts - bluegreen We&rsquo;re going to create this application in the argo-rollouts project - this is just for simplicity in the demo.
+Add &lsquo;bluegreen&rsquo; application stanza under Applications
+applications: &lt;... omitted ...&gt; bluegreen: name: bluegreen namespace: bluegreen project: argo-rollouts path: charts/all/bluegreen When finished editing make sure that you commit your changes to git!
+git commit -am &#34;Added blue-green application to the pattern&#34; git push -u origin main Our demo application is an example application that the argo project provides. We declare this image in the values-global.yaml file, and we will modify the tag to trigger the rollout.
+values-global.yaml
+rollout: image: argoproj/rollouts-demo:blue Review the snippet below to add bluegreen to the pattern!
+Check that the application deployed successfully in the argocd user interface. If everything went well you should see something like this:
+With our demo application deployed, let&rsquo;s a rollout by changing the image tag in values-global.yaml to green.
+Once we&rsquo;ve made the change we need to commit and push our changes to git
+git add values-global.yaml git commit -m &#34;triggering rollout with image update&#34; git push -u origin main Once argocd recognizes the update, the rollout controller will create a replicaset for the green application and will start the desired number of pods. The green application is using its own service and that service is exposed via a route. Once the replicaset has created the pods, the rollout will pause waiting for an action to either promote or abort the rollout.
+We have two ways of viewing the rollout. The first is through UI in the argocd interface, and the other is using the argocd rollouts plugin. The UI doesn&rsquo;t provide as much detail as the plugin, so I&rsquo;ll show you what both look like for reference.
+This is what the plugin shows us before the image tag has been detected:
+oc argo rollouts get rollout bluegreen Name: bluegreen Namespace: bluegreen Status: ✔ Healthy Strategy: BlueGreen Images: argoproj/rollouts-demo:blue (stable, active) Replicas: Desired: 2 Current: 2 Updated: 2 Ready: 2 Available: 2 NAME KIND STATUS AGE INFO ⟳ bluegreen Rollout ✔ Healthy 11m └──# revision:1 └──⧉ bluegreen-5f5746dc47 ReplicaSet ✔ Healthy 11m stable,active ├──□ bluegreen-5f5746dc47-5wfnt Pod ✔ Running 11m ready:1/1 └──□ bluegreen-5f5746dc47-q52cl Pod ✔ Running 11m ready:1/1 Once the image tag has been detected and the rollout executed, this is what we see:
+oc argo rollouts get rollout bluegreen Name: bluegreen Namespace: bluegreen Status: ॥ Paused Message: BlueGreenPause Strategy: BlueGreen Images: argoproj/rollouts-demo:blue (stable, active) argoproj/rollouts-demo:green (preview) Replicas: Desired: 2 Current: 4 Updated: 2 Ready: 2 Available: 2 NAME KIND STATUS AGE INFO ⟳ bluegreen Rollout ॥ Paused 13m ├──# revision:2 │ └──⧉ bluegreen-69d5bcb78 ReplicaSet ✔ Healthy 66s preview │ ├──□ bluegreen-69d5bcb78-d5bjp Pod ✔ Running 66s ready:1/1 │ └──□ bluegreen-69d5bcb78-vnw4q Pod ✔ Running 66s ready:1/1 └──# revision:1 └──⧉ bluegreen-5f5746dc47 ReplicaSet ✔ Healthy 13m stable,active ├──□ bluegreen-5f5746dc47-5wfnt Pod ✔ Running 13m ready:1/1 └──□ bluegreen-5f5746dc47-q52cl Pod ✔ Running 13m ready:1/1 In the argoCD interface this what the rollout looks like:
+If you look at the rollout resource you can see that it is paused. This is because it&rsquo;s waiting on an administrator to approve or cancel the deployment. Both applications are running side by side. Let&rsquo;s take a look at the routes!
+The active/blue/production route:
+The preview/update/new route:
+Now if we promote the application, the green application will become the primary.
+In the argoCD interface, click on the bluegreen application, in the application context click on the vertical ellipsis next to the bluegreen rollout, then click promote-full or click abortto back out.
+Now if we take a look at our active route we can see that the color changed to green!
+You could do the same with the argo rollouts plugin: kubectl argo rollouts promote bluegreen to back out of the rollout: kubectl argo rollouts abort bluegreen
+You can verify that the application has been promoted correctly by using the argo rollouts plugin, checking the route, or by checking the image tag in the rollout resource.
+oc argo rollouts get rollout bluegreen Name: bluegreen Namespace: bluegreen Status: ✔ Healthy Strategy: BlueGreen Images: argoproj/rollouts-demo:green (stable, active) Replicas: Desired: 2 Current: 2 Updated: 2 Ready: 2 Available: 2 NAME KIND STATUS AGE INFO ⟳ bluegreen Rollout ✔ Healthy 26m ├──# revision:2 │ └──⧉ bluegreen-69d5bcb78 ReplicaSet ✔ Healthy 13m stable,active │ ├──□ bluegreen-69d5bcb78-d5bjp Pod ✔ Running 13m ready:1/1 │ └──□ bluegreen-69d5bcb78-vnw4q Pod ✔ Running 13m ready:1/1 └──# revision:1 └──⧉ bluegreen-5f5746dc47 ReplicaSet • ScaledDown 26m That&rsquo;s it for the blue-green deployment! Now let&rsquo;s take a look at a canary deployment.
+Canary Rollout Canary deployments give us a lot of control on how our application is deployed. We can define what percentage of ingress traffic gets the canary or updated application and for how long. Rollouts can use metrics to determine the health of a rollout and make a decision to continue or abort the rollout based on those metrics.
+This gives us insight into the health of our application as it is deployed, it gives insights into whether features are being used, and if they&rsquo;re working correctly. It really does open up all kinds of opportunities to learn a lot more about our applications and how they&rsquo;re used! Canary deployments are powerful and add flexibility to our application deployments. Either through a full application deployment or just testing a feature.
+Let&rsquo;s get on with the demo!
+The canary demo is located in charts/all/canary-demo and similar to how we deployed the bluegreen demo, we need to add the canary-demo application to our pattern for argocd to deploy it.
+Add canary-demo namespace to the list of namespaces to be created by openshift-gitops namespaces: - open-cluster-management - vault - golang-external-secrets - argo-rollouts - canary-demo We&rsquo;re going to create this application in the argo-rollouts project - this is just for simplicity in the demo.
+Add &lsquo;canary-demo&rsquo; application stanza under Applications
+applications: &lt;... omitted ...&gt; bluegreen: name: canary-demo namespace: canary-demo project: argo-rollouts path: charts/all/canary-demo When finished editing make sure that you commit your changes to git!
+git commit -am &#34;Added canary application to the pattern&#34; git push -u origin main We can monitor the argocd interface for the application deployment. When the application has successfully deployed you should see something similar to the image below in the argocd interface:
+Let’s take a look at the rollout resource for the canary-demo application.
+oc get rollout -o yaml canary-demo -n canary-demo
+strategy: canary: steps: - setWeight: 20 - pause: {} - setWeight: 40 - pause: duration: 10 - setWeight: 60 - pause: duration: 10 - setWeight: 80 - pause: duration: 10 In the above snippet, we’re telling the rollout controller that we want 20% of the traffic setWeight: 20 to go to the canary for an indefinite amount of time pause: {}, in the next step we want 40% of the traffic to go to the canary for 10 seconds, then 60% for 10 seconds, then 80% for 10 seconds until 100% of the traffic is using the canary service. These values can be modified to whatever makes sense for our deployment, maybe 10 seconds isn’t long enough to collect performance data on our feature canary and we need to run it for a bit longer.
+Our active service before the rollout looks like this:
+So let&rsquo;s trigger a rollout by changing the image tag! Edit the values-global.yaml and change the tag from blue to red
+Make sure you push your changes to git!
+git commit -am &#34;Change canary image tag&#34; git push -u origin main When the canary rollout occurs it removes one pod from the existing replicaset to support the canary replicaset. Let&rsquo;s use the argo rollout plugin to see what this looks like:
+oc argo rollouts get rollout canary-demo Name: canary-demo Namespace: canary-demo Status: ॥ Paused Message: CanaryPauseStep Strategy: Canary Step: 1/8 SetWeight: 20 ActualWeight: 20 Images: argoproj/rollouts-demo:blue (stable) argoproj/rollouts-demo:red (canary) Replicas: Desired: 5 Current: 5 Updated: 1 Ready: 5 Available: 5 NAME KIND STATUS AGE INFO ⟳ canary-demo Rollout ॥ Paused 8m45s ├──# revision:2 │ └──⧉ canary-demo-6ffd7b9658 ReplicaSet ✔ Healthy 39s canary │ └──□ canary-demo-6ffd7b9658-dhhph Pod ✔ Running 38s ready:1/1 └──# revision:1 └──⧉ canary-demo-7d984ffb4c ReplicaSet ✔ Healthy 8m45s stable ├──□ canary-demo-7d984ffb4c-5hdsr Pod ✔ Running 8m45s ready:1/1 ├──□ canary-demo-7d984ffb4c-6wtjq Pod ✔ Running 8m45s ready:1/1 ├──□ canary-demo-7d984ffb4c-9vnq9 Pod ✔ Running 8m45s ready:1/1 └──□ canary-demo-7d984ffb4c-zh2bj Pod ✔ Running 8m45s ready:1/1 oc get replicasets NAME DESIRED CURRENT READY AGE canary-demo-6ffd7b9658 1 1 1 47s canary-demo-7d984ffb4c 4 4 4 8m53s In the argoCD interface we see that the rollout is paused just like with blue-green
+But what about our application - we said we only want 20% of the traffic to go to the new app:
+That is awesome! So now let&rsquo;s promote the application and see what happens - the expectation is that it will incrementally update the percentage of connections to the new application until completely promoted.
+Let&rsquo;s take a look at what it looks like using the argo rollouts plugin
+Conclusion Argo Rollouts makes progressive delivery of our applications super easy. Whether you want to deploy using blue-green or the more advanced canary rollout is up to you. The canary rollout is very powerful and as we saw gives us the ultimate control, with insights and flexibility to deploy applications. There is so much more that argo rollouts can do - this demo barely scratches the surface! Keep an eye out for argo rollouts as part of openshift-gitops in &lsquo;23.
+`,url:"https://validatedpatterns.io/blog/2022-11-20-argo-rollouts/",breadcrumb:"/blog/2022-11-20-argo-rollouts/"},"https://validatedpatterns.io/blog/2022-10-12-acm-provisioning/":{title:"Multi-cluster GitOps with Provisioning",tags:[],content:`Multi-cluster GitOps with Provisioning Introduction Validated Patterns are an opinionated GitOps environment that lowers the bar for those creating repeatable and declarative deployments. It’s value is most apparent when delivering demos and solutions that span multiple areas of our portfolio. Our skeleton allows folks to focus on what needs to be delivered while we take care of how to do so using best practices. This is further illustrated in the simplified way patterns use ACM to provision additional clusters.
+Not only do patterns allow a cluster to completely configure itself - including elements traditionally handled with scripting and extending beyond the cluster, but we can now also declaratively teach it about a set of clusters it should provision and subsequently configure.
+Let’s walk through an example using the Multi-Cloud GitOps pattern as an example…
+Preparation If you&rsquo;ve never deployed OpenShift before, you could try ROSA the pay-as-you-go OpenShift managed service.
+Installing a validated pattern Start by deploying the Multi-cloud GitOps pattern on AWS.
+Next, you&rsquo;ll need to create a fork of the multicloud-gitops repo. Go there in a browser, make sure you’re logged in to GitHub, click the “Fork” button, and confirm the destination by clicking the big green &ldquo;Create fork&rdquo; button.
+Now you have a copy of the pattern that you can make changes to. You can read more about the Multi-cloud GitOps pattern on our community site
+Next, install the Validated Patterns operator from Operator Hub.
+And finally, click through to the installed operator, and select the Create instance button and fill out the Create a Pattern form. Most of the defaults are fine, but make sure you update the GitSpec URL to point to your fork of multicloud-gitops, rather than https://github.com/validatedpatterns/multicloud-gitops.
+Providing your Cloud Credentials Secrets must never be stored in Git. Even in encrypted form, you likely also publish metadata that may be exploited to launch spear phishing, and waterholing attacks.
+The Multi-Cloud GitOps pattern uses HashiCorp&rsquo;s Vault for secure secret storage.
+In order to provision additional clusters, the hub will need your cloud credentials. To do this you can either manually load the secrets into the vault via the UI, or make use of the following process for loading them from a machine you control.
+Loading provisioning secrets First clone your fork of the repository onto your local machine, and copy the template to a location not controlled by Git (to avoid accidentally committing the contents)
+git clone git@github.com:{yourfork}/multicloud-gitops.git cp values-secret.yaml.template ~/values-secret.yaml You will need to uncomment and provide values for the following keys in order to make use of the provisioning functionality:
+secrets: aws: [1] aws_access_key_id: AKIAIOSFODNN7EXAMPLE aws_secret_access_key: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY files: publickey: ~/.ssh/id_rsa.pub [2] privatekey: ~/.ssh/id_rsa openshiftPullSecret: ~/.dockerconfigjson [3] [1] A guide to finding the relevant AWS values can be found here You might even have them in a ~/.aws/credentials file.
+[2] The public/private key-pair is used to allow access to OpenShift nodes for triage purposes.
+[3] The openshiftPullSecret is how Red Hat knows you’ve got a licence to install OpenShift. To obtain one, go here, save the contents, and provide that path in the secrets file. The contents should start with something like: {&quot;auths&quot;:{&quot;cloud.openshift.com&quot;:{&quot;auth&quot;:&quot;....
+Obtain the login command for your cluster and run it locally. Ensure podman is installed, and load the secrets with:
+./common/scripts/pattern-util.sh make load-secrets These values will be used to create a number of secrets that ACM expects in order to provision clusters.
+Loading Secrets into the Cluster Define a Managed Cluster Group Managed cluster groups are sets of clusters, grouped by function, that share a common configuration set. There is no limitation on the number of groups, or the number of clusters within each group, however IIUC there is a scaling limit of approximately 1000 clusters in total.
+The following is the example we will use today:
+managedClusterGroups: myFirstGroup: name: group-one labels: - name: clusterGroup value: group-one .name is significant here and defines which site file (values-{name}.yaml) is used as the cluster&rsquo;s bill-of-materials. In the example above, you would need to make sure that values-group-one.yaml existed at the top of the Git repo and contained a list of all the namespaces, subscriptions, and applications that should be delivered to the cluster.
+.labels tells ACM how to decide which clusters get this site configuration. If you were building and importing clusters yourself, these are the labels you would need to specify during the import process. You can specify different and/or additional labels, but the default is to use clusterGroup={name of the group}
+Create a Cluster Pool Validated Patterns use cluster pools to automatically provision and configure sets of spoke clusters in cloud environments (so far with a focus on testing AWS). You can even configure the pools to maintain a number of spare (hibernating) clusters, to provide rapid and cost-effective access to clusters on-demand and at scale.
+You can read more about cluster pools in the ACM documentation
+Defining the cluster pool Defining clusters Each managed cluster group can have multiple pools, here is an example:
+clusterPools: myFirstPool: name: aws-ap openshiftVersion: 4.10.18 baseDomain: blueprints.rhecoeng.com platform: aws: region: ap-southeast-2 size: 1 clusters: - tokyo - sydney - jakarta The most important thing to change is .baseDomain, which will need to correspond to a route53 domain associated with your account. We allow multiple pools per group so that the same cluster configuration can be delivered to multiple regions.
+You can specify as many clusters as your AWS limits will support. Feel free to choose something different than tokyo, sydney, and jakarta.
+If .size is omitted, the pool will automatically resize based on the number of clusters specified. Specifying no clusters will define the pool, but not provision any clusters.
+Delivering Applications and Configuration to Clusters Delivering Configuration Changes Deprovisioning Clusters As the provisioning data only exists on the ACM hub cluster, it is important to ensure any managed clusters are deprovisioned before the hub itself is destroyed. In general this involves scaling down the pool(s), and removing the entries in the clusters: list.
+You can see the process in action below:
+Deprovisioning clusters Conclusion Once entrusted with your cloud credentials, all patterns can drive the creation and subsequent configuration of complex cluster topologies (including hub-of-hubs!).
+`,url:"https://validatedpatterns.io/blog/2022-10-12-acm-provisioning/",breadcrumb:"/blog/2022-10-12-acm-provisioning/"},"https://validatedpatterns.io/blog/2022-09-02-route/":{title:"Using subdomain in your OpenShift route definitions",tags:[],content:`What Is a route in OpenShift? When creating Community or Validated Patterns using the Validated Patterns framework we often include application workloads, such as a UI, that will need to be accessed externally. A route allows developers to expose services through an HTTP(S) aware load balancing and proxy layer via a public DNS entry.
+How is the kind: Route used in OpenShift? If your application is meant to be used externally then you will need to define a route so that users can access the service using the URL you specify in the route definition.
+Here&rsquo;s a simple example of a route definition for a hello-openshift application:
+apiVersion: route.openshift.io/v1 kind: Route metadata: name: hello-openshift spec: host: hello-openshift-hello-openshift.&lt;Ingress_Domain&gt; port: targetPort: 8080 to: kind: Service name: hello-openshift As you can see the spec describes the a host: or path to the route, the target port (8080), and the target, or to: that resolves into endpoints.
+If we focus on the host: value you see that we need to provide the Ingress_Domain to the host. You might ask yourself: why is this a problem?
+If you manage just one cluster, and your application just runs on that cluster, you can just hard code the ingress domain and be on your merry way. But what happens when you are deploying this application to multiple clusters and their domains are different? Whoever is doing the Ops to deploy your application will have to change the Ingress_Domain to match the the cluster domain manually before deploying the application.
+Let&rsquo;s go a step further and say you are using GitOps, and this definition lives in a git repository, what happens then? In our humble opinion it becomes a bit more complicated to make sure the ingress domain is set correctly.
+The kind: Route spec to the rescue The route specification for openshift can be found here. If you look at the .spec section you can see the properties that can be used. The one that we will focus in the subdomain property. From our docs here&rsquo;s the definition of the subdomain property:
+subdomain is a DNS subdomain that is requested within the ingress controller’s domain (as a subdomain). If host is set this field is ignored. An ingress controller may choose to ignore this suggested name, in which case the controller will report the assigned name in the status.ingress array or refuse to admit the route. If this value is set and the server does not support this field host will be populated automatically. Otherwise host is left empty. The field may have multiple parts separated by a dot, but not all ingress controllers may honor the request. This field may not be changed after creation except by a user with the update routes/custom-host permission.
+Example: subdomain frontend automatically receives the router subdomain apps.mycluster.com to have a full hostname frontend.apps.mycluster.com.
+If you have access to an OpenShift cluster you can test the above route manifest to see the results. Let&rsquo;s create a quick route-example.yaml file and use the subdomain property. From the command line type the following:
+$ cat &lt;&lt;EOF &gt; /tmp/route-example.yaml apiVersion: route.openshift.io/v1 kind: Route metadata: name: hello-openshift namespace: hello-openshift spec: subdomain: hello-openshift-hello-openshift port: targetPort: 8080 to: kind: Service name: hello-openshift EOF Now let&rsquo;s create a namespace where we will test create our Route.
+$ oc create ns hello-openshift namespace/hello-openshift created Now let&rsquo;s change our context to that namespace.
+$ oc project hello-openshift Now using project &#34;hello-openshift&#34; on server &#34;https://api.magic-mirror-2.blueprints.rhecoeng.com:6443&#34;. Last but not least now let&rsquo;s apply that example route definition we just created.
+$ oc create -f /tmp/route-example.yaml route.route.openshift.io/hello-openshift created If we inspect what was applied to the OpenShift cluster you should be able to see the following:
+$ oc get route/hello-openshift -o yaml apiVersion: route.openshift.io/v1 kind: Route metadata: annotations: openshift.io/host.generated: &#34;true&#34; creationTimestamp: &#34;2022-09-02T21:55:58Z&#34; name: hello-openshift namespace: hello-openshift resourceVersion: &#34;1349531&#34; uid: c0cddbb2-271e-48fb-b7fd-bcd8c5075cdf spec: host: hello-openshift-hello-openshift.apps.magic-mirror-2.blueprints.rhecoeng.com port: targetPort: 8080 subdomain: hello-openshift-hello-openshift to: kind: Service name: hello-openshift weight: 100 wildcardPolicy: None status: ingress: - conditions: - lastTransitionTime: &#34;2022-09-02T21:55:58Z&#34; status: &#34;True&#34; type: Admitted host: hello-openshift-hello-openshift.apps.magic-mirror-2.blueprints.rhecoeng.com routerCanonicalHostname: router-default.apps.magic-mirror-2.blueprints.rhecoeng.com routerName: default wildcardPolicy: None As you can see the subdomain property was replaced with the host property but it includes the ingress domain for the cluster. Why is this important? I can now apply this to any OpenShift cluster without worrying it&rsquo;s ingress domain since it will get appended automatically.
+There is currently a known issue when using the subdomain property in which the name given is not published with the correct template, instead of that they are published with the default &lsquo;\${name}-\${namespace}.subdomain.local&rsquo;. This has been fixed and it&rsquo;s available in OpenShift 4.11.
+Conclusion Using the subdomain property when defining route is super useful if you are deploying your application to different clusters and it will allow you to not have to hard code the ingress domain for every cluster.
+If you have any questions or want to see what we are working on please feel free to visit our Validated Patterns site. If you are excited or intrigued by what you see here we’d love to hear your thoughts and ideas! Try the patterns contained in our Validated Patterns Repo. We will review your pull requests to our pattern repositories.
+`,url:"https://validatedpatterns.io/blog/2022-09-02-route/",breadcrumb:"/blog/2022-09-02-route/"},"https://validatedpatterns.io/blog/2022-08-24-clustergroups/":{title:"Using clusterGroups in the Validated Patterns Framework",tags:[],content:`What Is a clusterGroup? The Validated Patterns framework defines itself in terms of clusterGroups. A clusterGroup is a set of one or more Kubernetes clusters that are managed to have the same deployments (that is, subscriptions and applications, namespaces and projects) applied to each member of the same clustergroup. Two different members of the same clusterGroup will differ in cluster-name and in other cluster-specific details (such as PKI and tokens) but will have the same subscriptions and applications as other members of the same clusterGroup.
+Essentially, a clusterGroup is an abstract definition of what the pattern will install on each respective cluster in the pattern. It is possible to install multiple clusterGroups on the same cluster, as we do (for example) in Industrial Edge where we have both datacenter and factory clusterGroups, and the factory clusterGroup is installed on the datacenter cluster by default.
+Single-Cluster and Multi-Cluster Patterns Because Validated Patterns started as an Edge initiative, we designed the notion of multi-cluster patterns into the framework from the beginning. The first Validated Pattern, Industrial Edge models a central data-lake and an optional remote factory cluster. The factory cluster does not need the CI or test system, nor the central data lake. Since we have different configuration needs on the two types of cluster, we define them as different cluster groups.
+Other patterns only (so far) require a single cluster, since they model their Edge requirements in different ways. Medical Diagnosis brings a pre-provided set of data (which would ordinarily come in from Edge clusters). Ansible Edge GitOps has RHEL instances as its Edge environment, not OpenShift clusters - and it runs its VMs through OpenShift Virtualization so it only uses the one cluster. In these cases, it is simplest to designate the single cluster as a Hub cluster.
+Uses for a Hub Cluster in a Multi-Cluster Deployment But in multi-cluster deployments, it is often helpful to define a hierarchy. Even if there are exactly two clusters as part of a multi-cluster pattern, it may be helpful to define one as the &ldquo;hub&rdquo;, in case the pattern grows to more clusters later. Modern architectures can scale to many instances, in some cases thousands, and there are certain responsibilities that are convenient to define as &ldquo;central&rdquo; or &ldquo;hub&rdquo; functions. Some examples that exist in the Framework and its applications so far:
+Configuration Management (via Advanced Cluster Management, or by Ansible Automation Platform) Data Aggregation (via AMQ Streams) Continuous Integration/Continuous Delivery Pipelines (via OpenShift Pipelines) Data Visualization (via Grafana) Secrets storage and maintenance (via Vault and the External Secrets Operator) Some other potential uses for the &ldquo;hub&rdquo; role or function include:
+General &ldquo;control plane&rdquo; functions Metrics aggregation The hub role defines a place in the architecture to run these vital functions, while reserving capacity on the Edge for data gathering and pre-process functions.
+But this naturally brings up a question - what are the different roles we have considered in the Validated Patterns framework, and how should they be used?
+Types of clusterGroup While we describe the Validated Patterns framework as &ldquo;opinionated&rdquo;, we do not want to make it overly constricting. The framework currently considered two types of clusterGroups: Hub and non-hub. We consider &ldquo;Hub&rdquo; as a role, primarily, but it is also used as the default name for the Hub clusterGroup. There are two important aspects of a Hub clusterGroup:
+It is expected to be a singleton (there is expected to be a single hub cluster in the hub clusterGroup) There is expected to be a single Hub clusterGroup in a given pattern Generally, we expect that non-Hub clusterGroups will be Edge clusters, but this is not essential. A clusterGroup should have at least one cluster that it will apply to (otherwise, why define one?) and can have multiple clusters. The framework sets ArgoCD&rsquo;s ignoreMissingValueFiles setting to true unconditionally, and the framework also provides an extraValueFiles variable, which can define multiple optional additional values files on a per-clusterGroup basis.
+How the Hierarchy Works - the clustergroup Chart The clustergroup chart begins by looking in the pattern&rsquo;s values-global.yaml for the main.clusterGroupName value. This value is then used to compute the next values file to process - if the value of that variable is hub then the application(s) that are created will use both the values-global.yaml and values-hub.yaml files in the root of the pattern repository. The clusterGroup structure will then be parsed for name and isHubCluster values; namespaces, subscriptions, projects and applications will be applied. Any managedClusterGroups (on the hubCluster) will be defined in terms for Advanced Cluster Management (as is done in Industrial Edge). Because the factory match expression is very general (vendor In OpenShift) this will match the hub cluster and any cluster that is joined to the hub cluster&rsquo;s ACM instance.
+Frequently Asked Questions (FAQs) I have a single-cluster Pattern. Do I need to call my hub cluster &ldquo;hub&rdquo;? You can, but you do not have to. If you want to call it something other than hub:
+Define a different main.clusterGroupName value in values-global.yaml Create the values-yourhubgroupname.yaml in the root of your pattern repository. Make sure clusterGroup.name variable in values-yourhubgroupname.yaml matches your intended hub group. I have a multi-cluster Pattern. All of my Edge clusters will have the same configuration. Do I need multiple clusterGroups to model it? No! This is the exact scenario we had in mind when we designed clusterGroups. Just add multiple clusters with the same criteria you defined to the ACM instance on your hub cluster, and each cluster you add will get the same subscriptions and applications.
+I have a multi-cluster Pattern. How do I decide if I need multiple clusterGroups to model it? Do you have different subscriptions or applications that you plan to use on your different clusterGroups? If so, you should define different clusterGroups and define them as managedClusterGroups for your hub cluster.
+`,url:"https://validatedpatterns.io/blog/2022-08-24-clustergroups/",breadcrumb:"/blog/2022-08-24-clustergroups/"},"https://validatedpatterns.io/blog/2022-07-15-push-vs-pull/":{title:"Push or Pull?",tags:[],content:`Push or Pull? Strategies for Large Scale Technology Change Management on the Edge What is Technology Change Management? There is a segment of the technology industry dedicated to keeping track of what is changing in an IT environment, when and how. These include systems like Service Now, Remedy, JIRA, and others. This is definitely a kind of change management, and these systems are important - but the focus of this blog post is not how the work of change management is tracked, but the actual means and strategy of doing those changes.
+Edge technology solutions involve hardware and software, and they all require some kind of technology maintenance. Our focus here is on software maintenance - these task can involve updating applications, patching underlying operating systems, performing remote administration - restarting applications and services. Coordinating change for a complex application can be daunting for a centralized datacenter application - but on the Edge, where we have hundreds, thousands, maybe millions of devices and application instances to keep track of, it is harder.
+What Do You Mean, Push or Pull? In this article, we are going to discuss two primary strategies for systems that are responsible for making and recording changes on other systems. We are making the assumption here that the system in question is making changes and also recording the results of those changes for later review or troubleshooting. Highly regulated organizations often have audit requirements to show that their financial statements are accurate, and this means demonstrating that there are business processes in place to authorize and schedule changes.
+In this context, when we say &ldquo;Push&rdquo;, we mean that a hub or centralized system originates and makes changes on other systems. The key differentiator is that the &ldquo;Push&rdquo; system stays in contact with the managed system throughout the process of the change. The &ldquo;Push&rdquo; system may also keep a record of changes made for its own purposes.
+In a &ldquo;Pull&rdquo; system, on the other hand, the centralized system waits for managed systems to connect to it to get their configuration instructions. &ldquo;Pull&rdquo; systems often have agents that use a dedicated protocol to define changes. There may be several steps in a &ldquo;Pull&rdquo; conversation, as defined by the system. A &ldquo;Pull&rdquo; system might also be able to cache and apply a previous configuration. The key differentiator of a &ldquo;Pull&rdquo; system is that it does not need to maintain constant contact with the central system to do its work.
+Push and Pull, in this context represent &ldquo;strategies&rdquo; for managing change. A given system can have both &ldquo;push&rdquo; and &ldquo;pull&rdquo; aspects; for example, ansible has an ansible-pull command which clearly works in a &ldquo;pull&rdquo; mode, even though most people recognize ansible as being primarily a push based system. While specific systems or products may be mentioned, the goal is not to evaluate systems themselves, but to talk about the differences and the relative merits and pitfalls of push and pull as strategies for managing change.
+What do you mean by &ldquo;Large&rdquo;? The term &ldquo;Large&rdquo; is quoted because it can mean different things in different contexts. For change management systems, it can include, but is not necessarily limited to:
+The count of individual systems managed As an arbitrary number, a system that manages 10,000 systems could probably be considered &ldquo;large&rdquo; regardless of other considerations. But sheer numbers of managed systems are only one aspect in play here. But you may still have a &ldquo;large&rdquo; problem if you do not have that many instances. Sheer volume of managed systems impose many constraints on systems that have to change and track other systems - records of changes have to be stored and indexed; there has to be a way to represent the different desired configurations.
+The complexity of different configurations across those systems The number of configurations represented across your fleet might be a better predictor for how &ldquo;large&rdquo; the problem is. It is easier to manage 10 configurations with 1,000 instances each than to manage 50 configurations with 100 instances each, for example.
+The organizational involvement in managing configurations Fleets have a certain team overhead in managing them as they grow. Who decides what hardware gets deployed, and when? Who decides when new Operating System versions are rolled out? Who does testing? If there are several teams involved in these activities, the problem is almost certainly a &ldquo;large&rdquo; one.
+The geographic distribution of systems managed Another aspect of complexity is how widely dispersed the fleet is. It is easier to manage 10,000 instances in one or even two locations than it is to manage 5 instances in each of 2,000 locations. Geographic distribution also includes operating in multiple legal jurisdictions, and possible in multiple nations. These impose requirements of various kinds on systems and thus also on the systems responsible for maintaining and changing them.
+It feels like a &ldquo;large&rdquo; problem to you If none of the other criteria listed so far apply to you, but it still feels like a &ldquo;large&rdquo; problem to you, it probably is one.
+Managing Change - An Ongoing Challenge In a perfect world, we could deploy technology solutions that maintain themselves. We would not need to update them; they would know how to update themselves. They could coordinate outage times, and could ensure that they can run successfully on a proposed platform. They would know about their own security vulnerabilities, and know how to fix them. Best of all, they could take requests from their users, turn those into systematic improvements, and deploy them without any other interaction.
+What is the Edge? Are you laughing yet? Most of the work of IT administrators is done in one of the areas listed above. Even very competent IT organizations sometimes struggle balancing some of these priorities. One aspect of the current computing environment is the prominence of Edge computing, which places its focus on the devices and applications that use computing resources far from central clouds and data centers - these compute resources run in retail stores, in pharmacies, hospitals, and warehouses; they run in cars and sometimes even spacecraft. In Edge environments, compute resources have to deal with intermittent network connectivity, if they have network connectivity at all. Sometimes, groups of devices have access to local server resources - as might the case in a large retail store, or in a factory or warehouse - but sometimes the closest &ldquo;servers&rdquo; are in the cloud and centralized. One interesting aspect of Edge deployments is that there are often many copies of effectively the same deployment. A large chain retail store might deploy the same set of applications to each of its stores. In such an installation, there may be many devices of a single type installed in that location. Think of the number of personal computers or cash registers you can see at a large retail store, for example. It would not be unusual to have ten PCs and twenty cash registers (per store) in this kind of deployment. And a large retail chain could have hundreds or even thousands of locations. Newer technologies, like Internet of Things deployments, require an even higher degree of connectivity - the single retail store example we are considering could have three hundred cameras to manage, which would need to be integrated into its IoT stack. And there could be hundreds, or thousands, of sites just like this one. The scope and scale of systems to manage can get daunting very quickly.
+So, some of the defining qualities of Edge environments are: scale (anyone operating some edge installations probably has a lot of edge installations, and the success of their business depends on them operating more of them) and network limitations (whether there is a connection at all, and if so, how reliable it is; bandwidth - how much data it can transfer at a time; and latency - how long it takes to get where it is going). This makes making changes in these environments challenging, because it means keeping track of large numbers of entities in an environment where our ability to contact those entities and verify their status may be limited if it is present at all. But we still must make changes in those environments, because those solutions need maintenance - their platforms may need security updates; their operators may want to update application features and functionality. This requires us to make changes to these devices, and requires technology change management.
+Consideration: Workload Capacity Management Workload Capacity Management focuses on what is needed to manage the scale of deployments. With large Edge deployments, the work needs to get done, and that work needs to be replicated on every node in scope for the deployment - so the same job or configuration content may need to apply to hundreds, thousands, or more individual nodes. Since the control point (central or distributed) is different between push and pull based systems, how they distribute the work needed to distribute changes. Push based systems must send the work out directly; but pull-based systems can potentially overwhelm a centralized system with a &ldquo;thundering herd.&rdquo;
+Common Consideration: Inventory/Data Aggregation Inventory and Data Aggregation are crucial considerations for both kinds of systems. Inventory is the starting point for determining what systems are in scope for a given unit of work; data aggregation is important to them because as units of work get done, we often need proof or validation that the work was done. With large numbers of edge nodes, there are certain to be exceptions, and the ability to keep track of where the work is crucial to completing the task.
+Common Consideration: Authentication/Authorization Since these systems are responsible for making changes on devices, how they interact with authentication and authorization systems is an important aspect of how they work. Is the user who the user claims to be? Which users are allowed to make which changes? Authentication and authorization are things we must consider for systems that make changes. Additionally many large organizations have additional technology requirements for systems that can make changes to other systems.
+Common Consideration: Dealing with Network Interruptions In Edge deployments, network connectivity is by definition limited, unreliable, or non-existent. There are differences in how respective types of systems can detect and behave in the presence of network interruptions.
+Common Consideration: Eventual Consistency / Idempotence Regardless of whether a system is push-based or pull-based, it is valuable and useful for the configuration units managed by that system to be safe to apply and re-apply at will. This is the common meaning of the term idempotence. One strategy for minimizing the effect of many kinds of problems in large-scale configuration management is writing content that is idempotent, that is, the effect of running the same content multiple times is the same as the effect of running it once. Practically speaking, this means that such systems make changes only when they need to, and do not have &ldquo;side effects&rdquo;. This makes it safe to run the same configuration content on the same device many times, so if it cannot be determined whether a device has received a particular configuration or not, the solution would be to apply the configuration to it, and the devices should then be in the desired, known state when the configuration is done.
+Approach 1: Push Strategy The first approach we will consider is the &ldquo;push&rdquo; strategy. In a &ldquo;push&rdquo; strategy, the centralized change management system itself reaches out to managed devices and triggers updates in some way. This could involve making an API call to a device, logging in to a device through SSH, or using a dedicated client/server protocol. Red Hat&rsquo;s Ansible operates as a push-based system, where a central console reaches out to devices and manages them.
+Push Consideration: Workload Capacity Management A push based system has much more control over how it parcels out configuration workload, since it is in control of how configuration workloads are driven. It can more easily perceive its own load state, and potentially &ldquo;back off&rdquo; or &ldquo;throttle&rdquo; if it is processing too much work too quickly - or increase it if the scope of the desired change is smaller than the total designed capacity of the system. It is easier to influence the &ldquo;rate of change&rdquo; on a push-based system for this reason.
+Push Consideration: Dealing with Network Interruptions Push-based systems are at a disadvantage when dealing with network interruptions and limitations. The most common network failure scenarios are ambiguous: if an attempt to reach an individual device fails, is that because there was a problem with the device, or a problem with the network path to reach the device? The push-based system can only know things about the devices it manages when it is told. An additional potential with network interruption is that a device can successfully apply a unit of configuration change but can fail to report that because of a network problem - the report is dropped, for example, because of a network path outage or problem, or the central collection infrastructure was overwhelmed. In such a situation, it is best to have the option to re-apply the configuration, for which it is best if you can have the confidence that such configuration will not have any undesired side-effects, and will only make the changes it needs to make.
+Approach 2: Pull Strategy The second approach we will consider is the &ldquo;pull&rdquo; strategy. The key difference in the &ldquo;pull&rdquo; strategy is that devices themselves initiate communication with the central management system. They can do this by making a request to the management system (which can be a notification, API call, or some other mechanism). That is to say - the central management system &ldquo;waits&rdquo; for check-ins from the managed devices. Client-server Puppet is a pull-based system, in which managed devices reach out to server endpoints, which give the devices instructions on what configurations to apply to themselves. Puppet also has options for operating in a push-based model; historically this could be done through puppet kick, mcollective orchestration, application orchestration, or bolt.
+Pull Consideration: Workload Capacity Management Pull-based systems have some challenges in regard to workload capacity for the pieces that need to be centralized (particularly reporting and inventory functions). The reason for this is that the devices managed will not have a direct source of information about the load level of centralized infrastructure, unless this is provided by an API; some load balancing schemes can do this in a rudimentary way by directing new requests to an instance via a &ldquo;least connection&rdquo; balancing scheme. Large deployments typically have to design a system to stagger check-ins to ensure the system does not get overwhelmed by incoming requests.
+Pull Consideration: Authentication/Authorization Pull-based systems typically have agents that run on the systems that are managed, and as such are simpler to operate from an authentication and authorization standpoint. Agents on devices can often be given administrative privilege, and the practical authentication/authorization problems have to do with access to the central management console, and the ability to change the configurations distributed or see the inventory and reports of attempts to configure devices.
+Pull Consideration: Dealing with Network Interruptions Pull-based systems have a distinct advantage when they encounter network interruptions. While it is in no way safe to assume that a managed device is still present or relevant from the standpoint of central infrastructure, it is almost always safe for a device, when it finds it cannot connect central infrastructure, to assume that it is experiencing a temporary network outage, and to simply retry the operation later. Care must be taken, especially in large deployments, not to overwhelm central infrastructure with requests. Additionally, we must remember that since network interruption can occur at any time on the edge, that the operation we are interested in may indeed have completed successfully, but the device was simply unable to report this to us for some reason. As was the case for push-based systems, the best cure for this is to ensure that content can be safely re-applied as needed or desired.
+Conclusions Push and Pull based systems have different scaling challenges as they grow Push and Pull-based systems have different tradeoffs. It can be easier to manage a push-based system for smaller numbers of managed devices; some of the challenges of both styles clearly increase as systems grow to multiple thousands of nodes.
+Meanwhile, both push and pull based systems, as a practical matter, have to make sense and be usable for small installations as well as large, and grow and scale as smoothly as possible. Many installations will never face some or maybe even any of these challenges - and systems of both types must be easy to understand and learn, or else they will not be used.
+Pull-based systems are better for Edge uses despite scaling challenges Pull based systems can deal better with the network problems that are inherent with edge devices. When connectivity to central infrastructure is unreliable, pull-based systems can still operate. Pull-based systems can safely assume that a network partition is temporary, and thus do not suffer from the inherent ambiguity of &ldquo;could not reach target system&rdquo; kinds of errors.
+Idempotence matters more than whether a system is push or pull based The fix for nearly all the operational problems in large scale configurations management problems is to be able to apply the same configuration to the same device multiple times and expect the same result. This takes discipline and effort, but that effort pays off well in the end.
+To help scale, introduce a messaging or queuing layer to hold on to data in flight if possible Many of the operational considerations are related to limited network connectivity or overtaxing centralized infrastructure. Both of these problems can be mitigated significantly by introducing a messaging or queuing layer in the configuration management system to hold on to reports, results, and inventory updates until the system can confirm receipt and processing of those elements.
+`,url:"https://validatedpatterns.io/blog/2022-07-15-push-vs-pull/",breadcrumb:"/blog/2022-07-15-push-vs-pull/"},"https://validatedpatterns.io/blog/2022-06-30-ansible-edge-gitops/":{title:"Ansible Edge GitOps",tags:[],content:`Validated Pattern: Ansible Edge GitOps Ansible Edge GitOps: The Why and What As we have been working on new validated patterns and the pattern framework, we have seen a need and interest from the community in expanding the use cases covered by the framework to include other parts of the portfolio besides OpenShift. We understand the Edge computing environments are very complex, and while OpenShift may be the right choice for some Edge environments, it will not be feasible or practical for all of them. Can other environments besides Kubernetes-native ones benefit from GitOps? If so, what would those look like? This pattern works to answer those questions.
+GitOps is currently a hot topic in technology. It is a natural outgrowth of the Kubernetes approach in particular, and is informed by now decades of practice in managing large fleets of systems. But is GitOps a concept that is only for Kubernetes? Or can we use the techniques and patterns of GitOps in other systems as well? We believe that by applying specific practices and techniques to Ansible code, and using a Git repo as the authoritative source for configuration results, that we can do exactly that.
+One of the first problems we knew we would have to solve in developing this pattern was to work out how to model an Edge environment that was running Virtual Machines. We started with the assumption that we were going to use the Ansible Automation Platform Operator for OpenShift to manage these VMs. But how should we run the VMs themselves?
+It is certainly possible to use the different public cloud offerings to spin up instances within the clouds, but that would require a lot of maintenance to the pattern over the long haul to pay attention to different image types and to address any changes to the provisioning schemes the different clouds might make. Additionally, since the purpose of including VMs in this pattern is to model an Edge environment, modeling them as ordinary public cloud instances might seem odd. As a practical matter, the pattern user would have to keep track of the instances and spin them down when spinning down the pattern.
+To begin solving these problems, this pattern introduces OpenShift Virtualization to the pattern framework. While OpenShift Virtualization today supports AWS and on-prem baremetal clusters, we hope that it will also bring support to GCP and Azure in the not too distant future. The use of OpenShift Virtualization enables the simulated Edge environment to be modeled entirely in a single cluster, and any instances will be destroyed along with the cluster.
+The pattern itself focuses on the installation of a containerized application (Inductive Automation Ignition) on simulated kiosks running RHEL 8 in kiosk mode. This installation pattern is based on work Red Hat did with a customer in the Petrochemical industry.
+Highlight: Imperative and Declarative Automation, and GitOps The validated patterns framework has been committed to GitOps as a philosophy and operational practice since the beginning. The framework&rsquo;s use of ArgoCD as a mechanism for deploying applications and components is proof of our commitment to GitOps core principles of having a declared desired end state, and a designated agent to bring about that end state.
+Many decades of automation practice that focus on individual OS instances (whether they be virtual machines or baremetal) may lead us to believe that the only way to manage such instances is imperatively - that is, focusing on the steps required to configure a machine to the state you want it to be in as opposed to the actual end state you want.
+By way of example, consider a situation where you want an individual OS instance to synchronize its time to a source you specify. The imperative way to do this would be to write a script that does some or all of the following:
+Install the software that manages system time synchronization Write a configuration file for the service that specifies the time source in question If the configuration file or other configuration mechanism that influences the service has changed, restart the time synchronization service. Along the way, there are subtle differences between different operating systems, such as the name of the time synchronization package (ntp or chrony, for example); differences in which package manager to use; differences in configuration file formats; differences in service names. It is all rather a lot to consider, and the kinds of scripts that managed these sorts of things at scale, when written in Shell or Perl, could get quite convoluted.
+Meanwhile, would it not be great if we could put the focus on end state, instead of on the steps required to get to that end state? So we could specify what we want, and we could trust the framework to &ldquo;make it so&rdquo; for us? Languages that have this capability rose to the forefront of IT consciousness this century and became wildly popular - languages like Puppet, Chef, Salt and, of course, Ansible. (And yes, they all owe quite a lot to CFEngine, which has been around, and is still around.) The development and practices that grew up around these languages significantly influenced Kubernetes and its development in turn.
+Because these languages all provide a kind of hybrid model, they all have mechanisms that allow you to violate one or more of the core tenets of GitOps. For example, while many people run their configuration management code from a Git repository, none of these languages specifically require that, and all provide mechanisms to run in an ad-hoc mode. And yet, all of these languages have a fairly strong declarative flavor that can be used to specify configurations with them; again, this is not mandatory, but it is still quite common. So maybe there is a way to apply the stricter definitions of GitOps to these languages and include their use in a larger GitOps system.
+Even within Kubernetes, where have clearly have first-class support for declarative systems, there are aspects of configuration that we may want to make deterministic, but not explicitly code into a git repository. For example, best practice for cluster availability is to spread a worker pool over three different availability zones in a public cloud region. Which three zones should they be? Those decisions are bound to the region the cluster is installed in. Do the AZs themselves really matter, or is the only important constraint that there be three? These kinds of things are state that matters to operators, and an imperative framework for dealing with questions like this can vastly simplify the task of cluster administrators, who can then use this automation to create clusters in multiple regions and clouds and trust that resources will be optimized for maximum availability.
+Another crucial point of Declarative and Imperative systems is that it is impossible to conceive of a declarative system that does not have or require reconciliation loops. These reconciliation loops are by definition imperative processes. They often have additional conventions that apply - for example the convention that in Kubernetes Operators the reconciliation loop will change one thing, and then retry - but those processes are still inherently imperative.
+A final crucial point on Declarative and Imperative systems is that, especially when we are talking about Edge installations, many of the systems that are important parts of those ecosystems do not have the same level of support for declarative-style configuration management that server operating systems and layers like Kubernetes have. Here we consider crucial elements of Edge environments like routers, switches, access points, and other network gear; as we consider IoT sensors like IP Cameras, it seems unlikely that we will have a Kubernetes-native way to manage devices like these in the foreseeable future.
+With these points in mind, it seems that if we cannot bring devices to GitOps, perhaps we should bring GitOps to devices. Ansible has long been recognized for its ability to orchestrate and manage devices in an agentless model. Is there a way to run Ansible that we can recognize as a GitOps mechanism? We believe that there is, by using it with the Ansible Automation Platform components (formerly known as Tower), and recording the desired state in the git repository or repositories that the system uses. In doing so, we believe that we can and should bring GitOps to Edge environments.
+Highlight: Including Ansible in Validated Patterns A new element of this pattern is the use of the Ansible Automation Platform Operator, which we install in the hub cluster of the pattern.
+The Ansible Automation Platform Operator is the Kubernetes-native way of running AAP. It provides the Controller function, which supports Execution Environments. The pattern provides its own Execution Environment (with the definition files, so that you can see what is in it or customize it if you like), and loads its own Ansible content into the AAP instance. It uses a dynamic inventory technique to deal with certain aspects of running the VMs it manages under Kubernetes.
+The key function of AAP in this pattern is to configure and manage the kiosks. The included content takes the fresh templates, registers them to the Red Hat CDN, installs Firefox, configures kiosk mode, and then downloads and manages the Ignition application container so that both firefox and the application container start at boot time.
+The playbook that configures the kiosks is configured to run every 10 minutes on all kiosks, so that if there is some temporary error on the kiosk the configuration will simply attempt configuration again when the schedule tells it to.
+Highlight: Including Virtualization in Validated Patterns As discussed above, another key element in this pattern is the introduction of of OpenShift Virtualization to model the Edge environment with kiosks. The pattern installs the OpenShift Virtualization operator, configures it, and provisions a metal node in order to run the virtual machines. It is possible to emulate hardware acceleration, but the resulting VMs have terrible performance.
+The virtual machines we build as part of this pattern are x86_64 RHEL machines, but it should be straightforward to extend this pattern to model other architectures, or other operating systems or versions.
+The chart used to define the virtual machines is designed to be open and flexible - replacing the values.yaml file in the chart&rsquo;s directory will allow you to define different kinds of virtual machine sets; the chart may give you some ideas on how to manage virtual machines under OpenShift in a GitOps way.
+Highlight: Including RHEL in Validated Patterns One of the highlights of this pattern is the use of RHEL in it. There are a number of interesting developments in RHEL that we have been working on, and we expect to highlight more of these in future patterns. We expect that this pattern will be the basis for future patterns that include RHEL, Ansible, and/or Virtualization.
+Where do we go from here? We believe this pattern breaks some new and interesting ground in bringing Ansible, Virtualization, and RHEL to the validated pattern framework. Like all of our patterns, this pattern is Open Source, and we encourage you to use it, tinker with it, and submit your ideas, changes and fixes.
+Documentation for how to install the pattern is here, where there are detailed installation instructions, more technical details on the different components in the pattern (especially the use of AAP and OpenShift Virtualization), and some ideas for customization.
+`,url:"https://validatedpatterns.io/blog/2022-06-30-ansible-edge-gitops/",breadcrumb:"/blog/2022-06-30-ansible-edge-gitops/"},"https://validatedpatterns.io/patterns/ansible-edge-gitops/":{title:"Ansible Edge GitOps",tags:[],content:`Ansible Edge GitOps Background Organizations are interested in accelerating their deployment speeds and improving delivery quality in their Edge environments, where many devices may not fully or even partially embrace the GitOps philosophy. Further, there are VMs and other devices that can and should be managed with Ansible. This pattern explores some of the possibilities of using an OpenShift-based Ansible Automated Platform deployment and managing Edge devices, based on work done with a partner in the Chemical space.
+This pattern uses OpenShift Virtualization (the productization of Kubevirt) to simulate the Edge environment for VMs.
+Solution elements How to use a GitOps approach to manage virtual machines, either in public clouds (limited to AWS for technical reasons) or on-prem OpenShift installations How to integrate AAP into OpenShift How to manage Edge devices using AAP hosted in OpenShift Red Hat Technologies Red Hat OpenShift Container Platform (Kubernetes) Red Hat Ansible Automation Platform (formerly known as &ldquo;Ansible Tower&rdquo;) Red Hat OpenShift GitOps (ArgoCD) OpenShift Virtualization (Kubevirt) Red Hat Enterprise Linux 8 Other Technologies this Pattern Uses Hashicorp Vault External Secrets Operator Inductive Automation Ignition Architecture Similar to other patterns, this pattern starts with a central management hub, which hosts the AAP and Vault components.
+Logical architecture Physical Architecture Recorded Demo TBD
+Other Presentations Featuring this Pattern Registration Required What Next Getting Started: Deploying and Validating the Pattern `,url:"https://validatedpatterns.io/patterns/ansible-edge-gitops/",breadcrumb:"/patterns/ansible-edge-gitops/"},"https://validatedpatterns.io/patterns/devsecops/":{title:"Multicluster DevSecOps",tags:[],content:`Multicluster DevSecOps Background With this Pattern, we demonstrate a horizontal solution for multicluster DevSecOps use cases.
+It is derived from the multi-cloud GitOps pattern with added products to provide a complete DevSecOps workflow. This includes CI/CD pipelines with security gates; image scanning, signing and storage in a secure registry; deployment to secured clusters that provide advanced security monitoring and alerting.
+Solution elements How to use a GitOps approach to keep in control of configuration and operations How to centrally manage multiple clusters, including workloads How to build and deploy workloads across clusters using modern CI/CD How to deploy different security products into the pattern Red Hat Products Red Hat OpenShift Container Platform (Kubernetes) Red Hat Advanced Cluster Management (Open Cluster Management) Red Hat OpenShift GitOps (ArgoCD) Red Hat OpenShift Pipelines (Tekton) Red Hat Quay (container image registry with security features enabled) Red Hat Open Data Foundation (highly available storage) Red Hat Advanced Cluster Security (scanning and monitoring) Other technologies and products Hashicorp Vault community edition (secrets management) Context on Multicluster DevSecOps Effective cloud native DevSecOps is about securing both the platform and the applications deployed to the platform. Securing the applications deployed is also about securing the supply chain. Not all applications are built in-house. Confidence in external applications and technologies is critical. OpenShift Platform Plus enables DevSecOps for both platform and supply chain.
+OpenShift Platform Plus includes OpenShift Container Platform, Advanced Cluster Management, Advanced Cluster Security, OpenShift Data Foundation and Red Hat Quay. The capabilities delivered across these components combine to provide policy-based cluster lifecycle management and policy based risk and security management across your fleet of clusters. You can see the flow at the bottom of this graphic.
+The Hub cluster is where lifecycle, deployment, security, compliance and risk management policies are defined and is the central management point across clusters. DevSecOps for the platform includes pulling images from Red Hat’s registry, pulling day two configuration code from Git via our integration with ArgoCD, and ensuring that all optional operators are deployed and configured.
+Policy based deployment also specifies which admission controllers should be deployed to which clusters, including the ACS admission controller. The Hub also provides a unified view of health, security, risk and compliance across your fleet. We have many of these capabilities in place today, however, they each have their own UI. Over the next few releases, we will be working to provide an integrated multi-cluster user experience for admin, security and developer persona in the OpenShift Console.
+Demo Scenario The Multicluster DevSecOps Pattern / Demo Scenario reflects this by having 3 layers:
+Managed/Secured edge - the edge or production a more controlled environment. Devel - where AppDev, Testing etc. is happening Central Data Center / Hub - the cloud/core, (and ERP systems of course, not part of the demo). There are ways of combing these three clusters into a two cluster (hub/devel and secured/edge) and single cluster (all in one). The documentation provides instructions (TBD Link).
+Pattern Logical Architecture The following diagram explains how different roles have different concerns and focus when working with this distributed AL/ML architecture.
+In the Multi-Cluster DevSecOps architecture there are three logical types of sites.
+The Hub. This is where the cloud native infrastructure is monitored and managed. It performs cluster management, advanced cluster security and a secure image registry. Devel. This is where the development pipeline is hosted. Developers submit code builds to the pipeline and various security tools are used in the pipeline to mitigate the risk of harmful applications or code being deployed in production. Secured Production. This is where applications are securely deployed and monitored. Pattern Architecture Schema The following diagram shows various management functions, including products and components, that are deployed on central hub and managed clusters (Devel. and Prod.) in order to maintain secure clusters. Consider this the GitOps schema.
+The following diagram shows various development pipeline functions, including products and components, that are deployed on the central hub and development (Devel) clusters in order to provide security features and services for development pipelines. Consider this the DevSecOps schema.
+`,url:"https://validatedpatterns.io/patterns/devsecops/",breadcrumb:"/patterns/devsecops/"},"https://validatedpatterns.io/blog/2022-03-30-multicloud-gitops/":{title:"Multi-Cloud GitOps",tags:[],content:`Validated Pattern: Multi-Cloud GitOps Validated Patterns: The Story so far Our first foray into the realm of Validated Patterns was the adaptation of the MANUela application and its associated tooling to ArgoCD and Tekton, to demonstrate the deployment of a fairly involved IoT application designed to monitor industrial equipment and use AI/ML techniques to predict failure. This resulted in the Industrial Edge validated pattern, which you can see here.
+This was our first use of a framework to deploy a significant application, and we learned a lot by doing it. It was good to be faced with a number of problems in the “real world” before taking a look at what is really essential for the framework and why.
+All patterns have at least two parts: A “common” element (which we expect to be the basic framework that nearly all of our patterns will share) and a pattern-specific element, which uses the common pattern and expands on it with pattern-specific content. In the case of Industrial Edge, the common component included secret handling, installation of the GitOps operator, and installation of Red Hat Advanced Cluster Management. The pattern-specific components included the OpenShift Pipelines Operator, the AMQ Broker and Streams operators, Camel-K, the Seldon Operator, OpenDataHub, and Jupyter Notebooks and S3 storage buckets.
+Multi-Cloud GitOps: The Why and What After finishing with Industrial Edge, we recognized that there were some specific areas that we needed to tell a better story in. There were several areas where we thought we could improve the user experience in working with our tools and repos. And we recognized that the pattern might be a lot clearer in form and design to those of us who worked on it than an interested user from the open Internet.
+So we had several categories of work to do as we scoped this pattern:
+Make a clear starting point: Make a clear “entry point” into pattern development, and define the features that we think should be common to all patterns. This pattern should be usable as a template for both us and other users to be able to clone as a starting point for future pattern development. Make “common” common: Since this pattern is going to be foundational to future patterns, remove elements from the common framework that are not expected to be truly common to all future patterns (or at least a large subset of them). Many elements specific to Industrial Edge found their way into common; in some cases we thought those elements truly were common and later re-thought them. Improve secrets handling: Provide a secure credential store such that we can manage secrets in that store rather than primarily as YAML files on a developer workstation. Broker access to that secret store via the External Secrets Operator to ensure a level of modularity and allow users to choose different secret stores if they wish. We also want to integrate the usage of that secret store into the cluster and demonstrate how to use it. Improve support for cluster scalability: For the Industrial Edge pattern, the edge cluster was technically optional (we have a supported model where both the datacenter and factory applications can run on the same cluster). We want these patterns to be more clearly scalable, and we identified two categories of that kind of scalability: Clusters vary only in name, but run the same applications and the same workloads Clusters vary in workloads, sizing, and configuration, and allow for considerable variability. Many of the elements needed to support these were present in the initial framework, but it may not have been completely clear how to use these features, or they were couched in terms that only made sense to the people who worked on the pattern. This will now be clearer for future patterns, and we will continue to evolve the model with user and customer feedback.
+Key Learning: Submodules are hard, and probably not worth it Copy and Paste Git Submodules Git Subtrees We rejected the notion of copy and paste because we reasoned that once patterns diverged in their “common” layer it would be too difficult and painful to bring them back together later. More importantly, there would be no motivation to do so.
+In Industrial Edge, we decided to make common a git submodule. Git submodules have been a feature of git for a long time, originally intended to make compiling a large project with multiple libraries more straightforward, by having a parent repo and an arbitrary set of submodule repos. Git submodule requires a number of exceptions to the “typical” git workflow - the initial clone works differently, and keeping the submodule updated to date can trip users up. Most importantly, it requires the practical management of multiple repositories, which can make life difficult in disconnected environments, which are important to us to support. It was confusing for our engineers to understand how to contribute code to the submodule repository. Finally, user response to the exceptions they had to make because of submodules was universally negative.
+So going forward, because it is still important to have a common basis for patterns, and a clear mechanism and technical path to get updates to the common layer, we have moved to the subtree model as a mechanism for including common. This allows consumers of the pattern to treat the repo as a single entity instead of two, and does not require special syntax or commands to be run when switching branches, updating or, in many cases, contributing to common itself.
+Key Learning: Secrets Management One of our biggest challenges in following GitOps principles for the deployment of workloads is the handling of secrets. GitOps tells us that the git repo should be the source of truth - but we know that we should not store secrets directly in publicly accessible repositories. Previously, our patterns standardized the use of YAML files on the developer workstation as the de-facto authoritative secret store. This can be problematic for at least two reasons: for one, if two people are working on the same repo, which secret store is “right”? Secondly, it might be easier to retrieve credentials from a developer workstation due to information breach or theft. Our systems will not work without secrets, and we need to have a better way of working with them.
+Highlight: Multi-cloud GitOps is the “Minimum Viable Pattern” One of the goals of this pattern is to provide the minimal pattern that both demonstrates the goals, aims and purpose of the framework and does something that we think users will find interesting and valuable. We plan to use it as a starting point for our own future pattern development; and as such we can point to it as the pattern to clone and start with if a user wants to start their own pattern development from scratch.
+New Feature: Hub Cluster Vault instance In this pattern, we introduce the ability to reference upstream helm charts, and pass overrides to them in a native ArgoCD way. The first application we are treating this way is Hashicorp Vault. The use of Vault also allows us to make Vault the authoritative source of truth for secrets in the framework. This also improves our security posture by making it significantly easier to rotate secrets and have OpenShift “do the right thing” by re-deploying and re-starting workloads as necessary.
+For the purposes of shipping this pattern as a runnable demonstration, we take certain shortcuts with security that we understand are not best practices - storing the vault keys unencrypted on a developer drive, for example. If you intend to run code derived from this pattern in production, we strongly recommend you consider and follow the practices documented here.
+New Feature: External Secrets Operator While it is important to improve the story for secret handling in the pattern space overall, it is also important to provide space for multiple solutions inside patterns. Because of this, we include the external secrets operator, which in the pattern uses vault, but can be used to support a number of other secret providers, and can be extended to support secrets providers that it does not already support. Furthermore, the external secrets approach is less disruptive to existing applications, since it works by managing the secret objects applications are already used to consuming. Vault provides different options for integration, including the agent injector, but this approach is very specific to Vault and not clearly portable.
+In a similar note to the feature about Vault and secrets: the approach we take in this release of the pattern has some known security deficiencies. In RHACM prior to 2.5, policies containing secrets will not properly cloak the secrets in the policy objects, and will not properly encrypt the secrets at rest. RHACM 2.5+ includes a fromSecret function that will secure these secrets in transit and at rest in both of these ways. (Of course, any entity with cluster admin access can recover the contents of a secret object in the cluster.) One additional deficiency of this approach is that the lookup function we use in the policies to copy secrets only runs when the policy object is created or refreshed - which means there is not a mechanism within RHACM presently to detect when a secret has changed and the policy needs to be refreshed. We are hoping this functionality will be included in RHACM 2.6.
+New Feature: clusterGroups can have multiple cluster members Using Advanced Cluster Management, we can inject per-cluster configuration into the ArgoCD application definition. We do this, for example, with the global.hubClusterDomain and global.localClusterDomain variables, which are available to use in helm templates in applications that use the framework.
+This enables one of our key new features, the ability to deploy multiple clusters that differ only in local, cluster-defined ways (such as the FQDNs that they would publish for their routes). This is a need we determined when we were working on Industrial Edge, where we had to add the FQDN of the local cluster to a config map, for use in a browser application that was defined in kubernetes, but runs in a user’s browser.
+The config-demo namespace uses a deployment of the Red Hat Universal Base Image of httpd to demonstrate how to use the framework to pass variables from application definition to actual use in config maps. The config-demo app shows the management of a secret defined and securely transferred from the hub cluster to remote clusters, as well as allowing for the use of the hub cluster base domain and the local cluster base domain in configuration of applications running on either the hub or managed clusters.
+Where do we go from here? One of the next things we are committed to delivering in the new year is a pattern to extend the concept of GitOps to include elements that are outside of OpenShift and Kubernetes - specifically Red Hat Enterprise Linux nodes, including Red Hat Enterprise Linux For Edge nodes, as well as Red Hat Ansible Automation Platform.
+We plan on developing a number of new patterns throughout the new year, which will showcase various technologies. Keep watching this space for updates, and if you would like to get involved, visit our site at https://validatedpatterns.io!
+`,url:"https://validatedpatterns.io/blog/2022-03-30-multicloud-gitops/",breadcrumb:"/blog/2022-03-30-multicloud-gitops/"},"https://validatedpatterns.io/blog/2022-03-23-acm-mustonlyhave/":{title:"To musthave or to mustonlyhave",tags:[],content:`Recently a user reported an issue when using the multicloud-gitops pattern: Namely, after testing changes in a feature branch (adding a helm application), said changes were not appearing on the remote clusters.
+Preamble In the multicloud gitops pattern each cluster has to ArgoCD instances: the &ldquo;main&rdquo; one which has additional rights and a &ldquo;secondary&rdquo; one which is in charge to keep the user applications in sync. The workflow of the initial pattern deployment is the following:
+All helm charts and yaml files below are referenced directly from a remote git repo (the GitOps way). The branch being chosen is the one set to locally when running make install. In order to switch branch on an existing pattern, the user needs to run make upgrade. This will trigger a change in a helm variable pointing to the git revision which will then propagate throughout the cluster. make install gets invoked which calls helm install common/install. This will install the main ArgoCD instance on the HUB cluster. Step 1. will also do a helm install of the common/clustergroup chart. This will install a number of helm charts thanks to the customizable content defined in values-hub.yaml. Amongst other things it will install ACM, HashiCorp Vault, the External Secrets operator (and a few more) The helm chart for ACM will install it and push out some cluster policies in order to add the necessary yaml files to configure ArgoCD on the remote clusters that will join the ACM hub. It will create the main ArgoCD instance on the remote cluster and run the common/clustergroup helm chart The common/clustergroup chart will do it&rsquo;s thing like on the hub, except this time it will be the values-region-one.yaml file driving the list of things to be installed. The problem The problem manifested itself in the following way: The user deployed the pattern from the main branch on to the clusters. Then the git branched was changed to something else (feature-branch), a new helm chart/application was added to the regional cluster (so in values-region-one.yaml) and the changes were pushed (git push and make upgrade). After the push, the application would never show up on the regional cluster.
+The symptoms After a short investigation, it was clear that something was off when ACM was pushing the common/clustergroup Argo Application on to the regional cluster. We could observe the following yaml:
+$ oc get -n openshift-gitops application multicloud-gitops-region-one -o yaml ... project: default source: repoURL: &#39;https://github.com/mbaldessari/multicloud-gitops.git&#39; path: common/clustergroup targetRevision: feature-branch helm: valueFiles: - &gt;- https://github.com/mbaldessari/multicloud-gitops/raw/feature-branch/values-global.yaml - &gt;- https://github.com/mbaldessari/multicloud-gitops/raw/feature-branch/values-region-one.yaml - &gt;- https://github.com/mbaldessari/multicloud-gitops/raw/main/values-global.yaml - &gt;- https://github.com/mbaldessari/multicloud-gitops/raw/main/values-region-one.yaml ... That list under the valueFiles attribute was wrong. It still contained references to the old main branch. To make matters worse they were listed after feature-branch making the value files from the new branch effectively useless. It really seemed like ACM was not really pushing out the changed policy fully. It&rsquo;s as if a merge happened when an existing application was changed.
+Resolution The problem turned out to be in how we pushed out the ArgoCD Application via ACM. We did this:
+{% raw %}
+apiVersion: policy.open-cluster-management.io/v1 kind: Policy metadata: name: {{ .name }}-clustergroup-policy annotations: argocd.argoproj.io/sync-options: SkipDryRunOnMissingResource=true argocd.argoproj.io/compare-options: IgnoreExtraneous spec: remediationAction: enforce disabled: false policy-templates: - objectDefinition: apiVersion: policy.open-cluster-management.io/v1 kind: ConfigurationPolicy metadata: name: {{ .name }}-clustergroup-config spec: remediationAction: enforce severity: med namespaceSelector: exclude: - kube-* include: - default object-templates: - complianceType: musthave objectDefinition: apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: {{ $.Values.global.pattern }}-{{ .name }} namespace: openshift-gitops finalizers: - argoproj.io/finalizer spec: project: default source: repoURL: {{ coalesce .repoURL $.Values.global.repoURL }} targetRevision: {{ coalesce .targetRevision $.Values.global.targetRevision }} path: {{ default &#34;common/clustergroup&#34; .path }} helm: valueFiles: - &#34;{{ coalesce .valuesDirectoryURL $.Values.global.valuesDirectoryURL }}/values-global.yaml&#34; - &#34;{{ coalesce .valuesDirectoryURL $.Values.global.valuesDirectoryURL }}/values-{{ .name }}.yaml&#34; parameters: - name: global.repoURL value: $ARGOCD_APP_SOURCE_REPO_URL ... {% endraw %}
+The problem was entirely into the complianceType: musthave. Quoting the docs at https://access.redhat.com/documentation/en-us/red_hat_advanced_cluster_management_for_kubernetes/2.4/html-single/governance/index#configuration-policy-yaml-table we have three possibilities:
+mustonlyhave Indicates that an object must exist with the exact name and relevant fields. musthave Indicates an object must exist with the same name as specified object-template. The other fields in the template are a subset of what exists in the object. \`mustnothave\`\` Indicated that an object with the same name or labels cannot exist and need to be deleted, regardless of the specification or rules. So musthave does not imply that the object being applied is identical to what is specified in the policy. The actual consequence of that on a real deployment is the following:
+Existing object
+- foo: - a - b If the above template gets changed in ACM:
+- foo: - c - d The end result in case of &lsquo;musthave&rsquo; complianceType will be:
+- foo: - a - b - c - d Changing the complianceType to mustonlyhave fixed the issue as it enforced the template fully on the remote cluster and solved this issue.
+Thanks Special thanks to Ilkka Tengvall and Christian Stark for their help and patience.
+`,url:"https://validatedpatterns.io/blog/2022-03-23-acm-mustonlyhave/",breadcrumb:"/blog/2022-03-23-acm-mustonlyhave/"},"https://validatedpatterns.io/blog/2021-12-31-medical-diagnosis/":{title:"Medical Diagnosis",tags:[],content:`Validated Pattern: Medical Diagnosis Our team recently completed the development of a validated pattern that showcases the capabilities we have at our fingertips when we combine OpenShift and other cutting edge Red Hat technologies to deliver a solution.
+We&rsquo;ve taken an application defined imperatively in an Ansible playbook and converted it into GitOps style declarative kubernetes resources. Using the validated pattern framework we are able to deploy, manage and integrate with multiple cutting edge Red Hat technologies, and provide a capability that the initial deployment strategy didn&rsquo;t have available to it: a lifecycle. Everything you need to take this pattern for a spin is in git.
+Pattern Workflow The purpose of this pattern is to show how medical facilities can take full advantage of trained AI/ML models to identify anomalies in the body like pneumonia. From the medical personnel point of view it works with medical imagery equipment submitting an X-ray image into the application to start the workflow.
+The image is uploaded to an S3-compatible object storage. This upload triggers an event from the storage, “a new image has been uploaded”, that is sent into a Kafka topic. This topic is consumed by a KNative Eventing listener that triggers the launch of a KNative Serving instance. This instance is a containerimage with the AI/ML model and the needed processing functions. Based on the information from the event it received, the container retrieves the image from the object store, pre-processes it, makes a prediction on the risk of pneumonia using the AI/ML model, and saves the result. A notification of those results is sent to the medical staff as well.
+For a recorded demo deploying the pattern and seeing the dashboards available to the user, check out our docs page!
+Pattern Deployment To deploy this pattern, follow the instructions outlined on the getting-started page.
+What&rsquo;s happening? During the bootstrapping of the pattern, the initial openshift-gitops operator is deployed with the necessary custom resource definitions, and custom resources to deploy the datacenter-&lt;validated-pattern&gt; with references to the appropriate git repository and branch. Once the argoCD application deploys it will create all of the common resources which include advanced cluster manager, vault, and openshift-gitops. The pattern deployment begins with argo applying the helm templates to the cluster, ultimately resulting in all resources deploying and the xraylab dashboard being available via its route.
+The charts for the pattern deployment are located: $GIT_REPO_DIR/charts/datacenter/
+Pattern Deployed Technology Operator Upstream Project openshift data foundation (odf) ceph, rook, noobaa openshift-gitops argoCD openshift serverless knative amq streams kafka opendatahub opendatahub grafana grafana Challenges With the imperative dependence on the originating content, there were some resources that didn&rsquo;t align 1:1 and needed to be overcome. For example, there are a number of tasks that are interrogating the cluster for information to transform into a variable and finally apply that variable to some resource. As you can imagine, this can be very challenging when you&rsquo;re declaring the state of your cluster. In order to maneuver around these imperative actions we took what we could and created openshift jobs to execute the task.
+Conclusion Speed, accuracy, efficiency all come to mind when considering what this pattern provides. Patients get the treatment they need, when they need it because we&rsquo;re able to use technology to quickly and accurately diagnosis anomalies detected in X-rays. The validated patterns framework enables administrators to quickly meet their user demands by providing solutions that only require them to bring their own data to complete the last 20-25% of the architecture.
+`,url:"https://validatedpatterns.io/blog/2021-12-31-medical-diagnosis/",breadcrumb:"/blog/2021-12-31-medical-diagnosis/"},"https://validatedpatterns.io/patterns/multicloud-gitops/":{title:"Multicloud GitOps",tags:[],content:` About the Multicloud GitOps pattern Use case Use a GitOps approach to manage hybrid and multi-cloud deployments across both public and private clouds.
+Enable cross-cluster governance and application lifecycle management.
+Securely manage secrets across the deployment.
+Based on the requirements of a specific implementation, certain details might differ. However, all validated patterns that are based on a portfolio architecture, generalize one or more successful deployments of a use case.
+Background Organizations are aiming to develop, deploy, and operate applications on an open hybrid cloud in a stable, simple, and secure way. This hybrid strategy includes multi-cloud deployments where workloads might be running on multiple clusters and on multiple clouds, private or public. This strategy requires an infrastructure-as-code approach: GitOps. GitOps uses Git repositories as a single source of truth to deliver infrastructure-as-code. Submitted code will be checked by the continuous integration (CI) process, while the continuous delivery (CD) process checks and applies requirements for things like security, infrastructure-as-code, or any other boundaries set for the application framework. All changes to code are tracked, making updates easy while also providing version control should a rollback be needed.
+About the solution This architecture covers hybrid and multi-cloud management with GitOps as shown in following figure. At a high level this requires a management hub, for DevOps and GitOps, and infrastructure that extends to one or more managed clusters running on private or public clouds. The automated infrastructure-as-code approach can manage the versioning of components and deploy according to the infrastructure-as-code configuration.
+Benefits of Hybrid Multicloud management with GitOps:
+Unify management across cloud environments.
+Dynamic infrastructure security.
+Infrastructural continuous delivery best practices.
+Figure 1. Overview of the solution including the business drivers, management hub, and the clusters under management In the following figure, logically, this solution can be viewed as being composed of an automation component, unified management including secrets management, and the clusters under management, all running on top of a user-chosen mixture of on-premise data centers and public clouds.
+Figure 2. Logical diagram of hybrid multi-cloud management with GitOps About the technology The following technologies are used in this solution:
+Red Hat OpenShift Platform An enterprise-ready Kubernetes container platform built for an open hybrid cloud strategy. It provides a consistent application platform to manage hybrid cloud, public cloud, and edge deployments. It delivers a complete application platform for both traditional and cloud-native applications, allowing them to run anywhere. OpenShift has a pre-configured, pre-installed, and self-updating monitoring stack that provides monitoring for core platform components. It also enables the use of external secret management systems, for example, HashiCorp Vault in this case, to securely add secrets into the OpenShift platform.
+Red Hat OpenShift GitOps A declarative application continuous delivery tool for Kubernetes based on the ArgoCD project. Application definitions, configurations, and environments are declarative and version controlled in Git. It can automatically push the desired application state into a cluster, quickly find out if the application state is in sync with the desired state, and manage applications in multi-cluster environments.
+Red Hat Advanced Cluster Management for Kubernetes Controls clusters and applications from a single console, with built-in security policies. Extends the value of Red Hat OpenShift by deploying apps, managing multiple clusters, and enforcing policies across multiple clusters at scale.
+Red Hat Ansible Automation Platform Provides an enterprise framework for building and operating IT automation at scale across hybrid clouds including edge deployments. It enables users across an organization to create, share, and manage automation, from development and operations to security and network teams.
+Hashicorp Vault Provides a secure centralized store for dynamic infrastructure and applications across clusters, including over low-trust networks between clouds and data centers.
+This solution also uses a variety of observability tools including the Prometheus monitoring and Grafana dashboard that are integrated with OpenShift as well as components of the Observatorium meta-project which includes Thanos and the Loki API.
+Overview of the architectures The following figure provides a schematic diagram overview of the complete solution including both components and data flows.
+Figure 3. Overview schematic diagram of the complete solution Subsequent schematic diagrams provide details on:
+Bootstrapping the management hub (Figure 4)
+Hybrid multi-cloud GitOps (Figure 5)
+Dynamic security management (Figure 6)
+Bootstrapping the management hub The following figure provides a schematic diagram showing the setup of the management hub using Ansible playbooks.
+Figure 4. Schematic diagram of bootstrapping the management hub Set up the OpenShift Container Platform that hosts the Management Hub. The OpenShift installation program provides flexible ways to install OpenShift. An Ansible playbook starts the installation with necessary configurations.
+Ansible playbooks deploy and configure Red Hat Advanced Cluster Management for Kubernetes and, later, other supporting components such as external secrets management, on top of the provisioned OpenShift cluster.
+Another Ansible playbook installs HashiCorp Vault, a Red Hat partner product chosen for this solution that can be used to manage secrets for OpenShift clusters.
+An Ansible playbook configures and installs the Openshift GitOps operator on the hub cluster. This deploys the Openshift GitOps instance to enable continuous delivery.
+Hybrid Multicloud GitOps The following figure provides a schematic diagram showing remaining activities associated with setting up the management hub and clusters using Red Hat Advanced Cluster Management.
+Figure 5. Schematic diagram of hybrid multi-cloud management with GitOps Manifest and configuration are set as code template in the form of a Kustomization YAML file. The file describes the desired end state of the managed cluster. When complete, the Kustomization YAML file is pushed into the source control management repository with a version assigned to each update.
+OpenShift GitOps monitors the repository and detects changes in the repository.
+OpenShift GitOps creates and updates the manifest by creating Kubernetes objects on top of Red Hat Advanced Cluster Management.
+Red Hat Advanced Cluster Management provisions, updates, or deletes managed clusters and configuration according to the manifest. In the manifest, you can configure what cloud provider the cluster will be on, the name of the cluster, infrastructure node details and worker node. Governance policy can also be applied as well as provision an agent in the cluster as the bridge between the control center and the managed cluster.
+OpenShift GitOps continuously monitors the code repository and the status of the clusters reported back to Red Hat Advanced Cluster Management. Any configuration drift or in case of any failure, OpenShift GitOps will automatically try to remediate by applying the manifest or by displaying alerts for manual intervention.
+Dynamic security management The following figure provides a schematic diagram showing how secrets are handled in this solution.
+Figure 6. Schematic showing the setup and use of external secrets management During setup, the token to securely access HashiCorp Vault is stored in Ansible Vault. It is encrypted to protect sensitive content.
+Red Hat Advanced Cluster Management for Kubernetes acquires the token from Ansible Vault during install and distributes it among the clusters. As a result, you have centralized control over the managed clusters through RHACM.
+To allow the cluster access to the external vault, you must set up the external secret management with Helm in this study. OpenShift Gitops is used to deploy the external secret object to a managed cluster.
+External secret management fetches secrets from HashiCorp Vault by using the token that was generated in step 2 and constantly monitors for updates.
+Secrets are created in each namespace, where applications can use them.
+Additional resources View and download all of the diagrams above from the Red Hat Portfolio Architecture open source tooling site.
+Presentation View a short presentation slide deck about Multicloud GitOps here
+Next steps Deploy the management hub using Helm.
+Add a managed cluster to deploy the managed cluster piece using ACM.
+`,url:"https://validatedpatterns.io/patterns/multicloud-gitops/",breadcrumb:"/patterns/multicloud-gitops/"},"https://validatedpatterns.io/patterns/industrial-edge/":{title:"Industrial Edge",tags:[],content:`Industrial Edge Pattern Red Hat Validated Patterns are detailed deployments created for different use cases. These pre-defined computing configurations bring together the Red Hat portfolio and technology ecosystem to help you stand up your architectures faster. Example application code is provided as a demonstration, along with the various open source projects and Red Hat products required for the deployment to work. Users can then modify the pattern for their own specific application.
+Use Case: Boosting manufacturing efficiency and product quality with artificial intelligence/machine learning (AI/ML) out to the edge of the network.
+Background: Microcontrollers and other types of simple computers have long been widely used on factory floors and processing plants to monitor and control the many machines required to implement the many machines required to implement many modern manufacturing workflows. The manufacturing industry has consistently used technology to fuel innovation, production optimization, and operations. However, historically, control systems were mostly “dumb” in that they mostly took actions in response to pre-programmed triggers and heuristics. For example, predictive maintenance commonly took place on either a set length of time or the number of hours was in service. Supervisory control and data acquisition (SCADA) has often been used to collectively describe these hardware and software systems, which mostly functioned independently of the company’s information technology (IT) systems. Companies increasingly see the benefit of bridging these operational technology (OT) systems with their IT. Factory systems can be much more flexible as a result. They can also benefit from newer technologies such as AI/ML, thereby allowing for tasks like maintenance to be scheduled based on multiple real-time measurements rather than simple programmed triggers while bringing processing power closer to data.
+Solution Overview Figure 1. Industrial edge solution overview.
+Figure 1 provides an overview of the industrial edge solution. It is applicable across a number of verticals including manufacturing.
+This solution:
+Provides real-time insights from the edge to the core datacenter Secures GitOps and DevOps management across core and factory sites Provides AI/ML tools that can reduce maintenance costs Different roles within an organization have different concerns and areas of focus when working with this distributed AL/ML architecture across two logical types of sites: the core datacenter and the factories. (As shown in Figure 2.)
+The core datacenter. This is where data scientists, developers, and operations personnel apply the changes to their models, application code, and configurations. The factories. This is where new applications, updates and operational changes are deployed to improve quality and efficiency in the factory.. Figure 2. Mapping of organizational roles to architectural areas.
+Figure 3. Overall data flows of solution.
+Figure 3 provides a different high-level view of the solution with a focus on the two major dataflow streams.
+Moving sensor data and events from the operational/shop floor edge towards the core. The idea is to centralize as much as possible, but decentralize as needed. For example, sensitive production data might not be allowed to leave the premises. Think of a temperature curve of an industrial oven; it might be considered crucial intellectual property of the customer. Or the sheer amount of raw data (maybe 10,000 events per second) might be too expensive to transfer to a cloud datacenter. In the above diagram, this is from left to right. In other diagrams the edge / operational level is usually at the bottom and the enterprise/cloud level at the top. Thus, this is also referred to as northbound traffic.
+Push code, configuration, master data, and machine learning models from the core (where development, testing, and training is happening) towards the edge / shop floors. As there might be 100 plants with 1000s of lines, automation and consistency is key. In the above diagram, this is from right to left, in a top/down view, it is called southbound traffic.
+Logical Diagrams Figure 4: Industrial Edge solution as logically and physically distributed across multiple sites.
+The following technology was chosen for this solution as depicted logically in Figure 4.
+The Technology Red Hat OpenShift is an enterprise-ready Kubernetes container platform built for an open hybrid cloud strategy. It provides a consistent application platform to manage hybrid cloud, public cloud, and edge deployments. It delivers a complete application platform for both traditional and cloud-native applications, allowing them to run anywhere.
+Red Hat Application Foundations (also sold as Red Hat Integration) includes frameworks and capabilities for designing, building, deploying, connecting, securing, and scaling cloud-native applications, including foundational patterns like microservices, API-first, and data streaming. When combined with Red Hat OpenShift, Application Foundations creates a hybrid cloud platform for development and operations teams to build and modernize applications efficiently and with attention to security, while balancing developer choice and flexibility with operational control. It includes, among other components::
+Red Hat Runtimes is a set of products, tools, and components for developing and maintaining cloud-native applications. It offers lightweight runtimes and frameworks for highly distributed cloud architectures, such as microservices. Built on proven open source technologies, it provides development teams with multiple modernization options to enable a smooth transition to the cloud for existing applications.
+Red Hat AMQ is a massively scalable, distributed, and high-performance data streaming platform based on the Apache Kafka project. It offers a distributed backbone that allows microservices and other applications to share data with high throughput and low latency.
+Red Hat Data Foundation is software-defined storage for containers. Engineered as the data and storage services platform for Red Hat OpenShift, Red Hat Data Foundation helps teams develop and deploy applications quickly and efficiently across clouds. It is based on the open source Ceph, Rook, and Noobaa projects.
+Red Hat Advanced Cluster Management for Kubernetes (RHACM) controls clusters and applications from a single console, with built-in security policies. It extends the value of Red Hat OpenShift by deploying applications, managing multiple clusters, and enforcing policies across multiple clusters at scale.
+Red Hat Enterprise Linux is the world’s leading enterprise Linux platform. It’s an open source operating system (OS). It’s the foundation from which you can scale existing apps—and roll out emerging technologies—across bare-metal, virtual, container, and all types of cloud environments.
+Architectures Edge manufacturing with messaging and ML Figure 5: Industrial Edge solution showing messaging and ML components schematically.
+As shown in Figure 5, data coming from sensors is transmitted over MQTT (Message Queuing Telemetry Transport) to Red Hat AMQ, which routes sensor data for two purposes: model development in the core data center and live inference in the factory data centers. The data is then relayed on to Red Hat AMQ for further distribution within the factory datacenter and out to the core datacenter. MQTT is the most commonly used messaging protocol for Internet of Things (IoT) applications.
+The lightweight Apache Camel K, a lightweight integration framework built on Apache Camel that runs natively on Kubernetes, provides MQTT (Message Queuing Telemetry Transport) integration that normalizes and routes sensor data to the other components.
+That sensor data is mirrored into a data lake that is provided by Red Hat OpenShift Data Foundation. Data scientists then use various tools from the open source Open Data Hub project to perform model development and training, pulling and analyzing content from the data lake into notebooks where they can apply ML frameworks.
+Once the models have been tuned and are deemed ready for production, the artifacts are committed to git which kicks off an image build of the model using OpenShift Pipelines (based on the upstream Tekton), a serverless CI/CD system that runs pipelines with all the required dependencies in isolated containers.
+The model image is pushed into OpenShift’s integrated registry running in the core datacenter which is then pushed back down to the factory datacenter for use in inference.
+Figure 6: Industrial Edge solution showing network flows schematically.
+As shown in Figure 6, in order to protect the factories and operations infrastructure from cyber attacks, the operations network needs to be segregated from the enterprise IT network and the public internet. The factory machinery, controllers, and devices need to be further segregated from the factory data center and need to be protected behind a firewall.
+Edge manufacturing with GitOps Figure 7: Industrial Edge solution showing a schematic view of the GitOps workflows.
+GitOps is an operational framework that takes DevOps best practices used for application development such as version control, collaboration, compliance, and CI/CD, and applies them to infrastructure automation. Figure 6 shows how, for these industrial edge manufacturing environments, GitOps provides a consistent, declarative approach to managing individual cluster changes and upgrades across the centralized and edge sites. Any changes to configuration and applications can be automatically pushed into operational systems at the factory.
+Secrets exchange and management Figure 8: Schematic view of secrets exchange and management in an Industrial Edge solution.
+Authentication is used to securely deploy and update components across multiple locations. The credentials are stored using a secrets management solution like Hashicorp Vault. The external secrets component is used to integrate various secrets management tools (AWS Secrets Manager, Google Secrets Manager, Azure Key Vault). As shown in Figure 7, these secrets are then passed to Red Hat Advanced Cluster Management for Kubernetes (RHACM) which pushes the secrets to the RHACM agent at the edge clusters based on policy. RHACM is also responsible for providing secrets to OpenShift for GitOps workflows( using Tekton and Argo CD).
+For logical, physical and dataflow diagrams, please see excellent work done by the Red Hat Portfolio Architecture team
+Demo Scenario This scenario is derived from the MANUela work done by Red Hat Middleware Solution Architects in Germany in 2019/20. The name MANUela stands for MANUfacturing Edge Lightweight Accelerator, you will see this acronym in a lot of artifacts. It was developed on a platform called stormshift.
+The demo has been updated 2021 with an advanced GitOps framework.
+Figure 9. High-level demo summary. The specific example is machine condition monitoring based on sensor data in an industrial setting, using AI/ML. It could be easily extended to other use cases such as predictive maintenance, or other verticals.
+The demo scenario reflects the data flows described earlier and shown in Figure 3 by having three layers.
+Line Data Server: the far edge, at the shop floor level.
+Factory Data Center: the near edge, at the plant, but in a more controlled environment.
+Central Data Center: the cloud/core, where ML model training, application development, testing, and related work happens. (Along with ERP systems and other centralized functions that are not part of this demo.)
+The northbound traffic of sensor data is visible in Figure 9. It flows from the sensor at the bottom via MQTT to the factory, where it is split into two streams: one to be fed into an ML model for anomaly detection and another one to be streamed up to the central data center via event streaming (using Kafka) to be stored for model training.
+The southbound traffic is abstracted in the App-Dev / Pipeline box at the top. This is where GitOps kicks in to push config or version changes down into the factories.
+Demo Script To deploy the Industrial Edge Pattern demo yourself, follow the demo script
+Download diagrams View and download all of the diagrams above in our open source tooling site.
+[Open Diagrams]
+Pattern Structure Presentation View a presentation slide deck about Industrial Edge here
+`,url:"https://validatedpatterns.io/patterns/industrial-edge/",breadcrumb:"/patterns/industrial-edge/"},"https://validatedpatterns.io/patterns/medical-diagnosis/":{title:"Medical Diagnosis",tags:[],content:`About the Medical Diagnosis pattern Background This validated pattern is based on a demo implementation of an automated data pipeline for chest X-ray analysis that was previously developed by Red Hat. You can find the original demonstration here. It was developed for the US Department of Veteran Affairs.
+This validated pattern includes the same functionality as the original demonstration. The difference is that this solution uses the GitOps framework to deploy the pattern including Operators, creation of namespaces, and cluster configuration. Using GitOps provides an efficient means of implementing continuous deployment.
+Workflow Ingest chest X-rays from a simulated X-ray machine and puts them into an objectStore based on Ceph.
+The objectStore sends a notification to a Kafka topic.
+A KNative Eventing listener to the topic triggers a KNative Serving function.
+An ML-trained model running in a container makes a risk assessment of Pneumonia for incoming images.
+A Grafana dashboard displays the pipeline in real time, along with images incoming, processed, anonymized, and full metrics collected from Prometheus.
+This pipeline is showcased in this video.
+About the solution elements The solution aids the understanding of the following:
+How to use a GitOps approach to keep in control of configuration and operations.
+How to deploy AI/ML technologies for medical diagnosis using GitOps.
+The Medical Diagnosis pattern uses the following products and technologies:
+Red Hat OpenShift Container Platform for container orchestration
+Red Hat OpenShift GitOps, a GitOps continuous delivery (CD) solution
+Red Hat AMQ, an event streaming platform based on the Apache Kafka
+Red Hat OpenShift Serverless for event-driven applications
+Red Hat OpenShift Data Foundation for cloud native storage capabilities
+Grafana Operator to manage and share Grafana dashboards, data sources, and so on
+S3 storage
+About the architecture Presently, the Medical Diagnosis pattern does not have an edge component. Edge deployment capabilities are planned as part of the pattern architecture for a future release.
+Components are running on OpenShift either at the data center, at the medical facility, or public cloud running OpenShift.
+About the physical schema The following diagram shows the components that are deployed with the various networks that connect them.
+The following diagram shows the components that are deployed with the the data flows and API calls between them.
+Recorded demo Presentation View presentation for the Medical Diagnosis Validated Pattern here
+Demo Script Use this demo script to successfully complete the Medical Diagnosis pattern demo here
+Next steps Getting started Deploy the Pattern
+`,url:"https://validatedpatterns.io/patterns/medical-diagnosis/",breadcrumb:"/patterns/medical-diagnosis/"},"https://validatedpatterns.io/patterns/industrial-edge/demo-script/":{title:"",tags:[],content:`Industrial Edge Deployment Script Objectives There&rsquo;s no experience like hands-on experience and being able to see industrial edge scenarios. This is a demo for the Industrial Edge Validated Pattern using the latest product and technology improvements.
+Show Red Hat Operators being deployed Show available Red Hat Pipelines for the Industrial Edge pattern Show the seed pipeline running and explain what is is doing Demonstration of the Red Hat ArgoCD views Show the openshift-gitops-server view Show the datacenter-gitops-server view Show the factory-gitops-server view For Information on the Red Hat Validated Patterns, visit our website See the pattern in action Watch the following video for a demonstration of OpenShift Pipelines in the Industrial Edge Pattern
+In this article, we give an overview of the demo and step by step instructions on how to get started.
+Getting Started NOTE: This demo takes a &ldquo;bring your own cluster&rdquo; approach, which means this pattern/demo will not deploy any OpenShift clusters.
+This demo script begins after the completion of you running ./pattern.sh make install from our Getting Started Guide
+Demo: Quick Health Check NOTE: This is a complex setup, and sometimes things can go wrong. Do a quick check of the essentials:
+There is an initial Seed Pipeline run in namespace manuela-ci that builds all required container images into the local registry. Check that the run was successful like this:
+If it did fail, try “Rerun” on the Pipeline run page:
+Check that the “Line Dashboard” in the development namespace is showing Data. The Link is in the bottom of the email under “Deployed Applications”. The Application should open - click on the “Realtime Data” Navigation on the left and wait a bit. Data should be visualized as received. Note that there is only vibration data! We will soon change that and activate temperature data also.
+If you wait a bit more (usually every 2-3 minutes), you will see an anomaly and alert (which is created by an ML Model)
+ArgoCD - all healthy and synced? Login to the datacenter Argo. Link and password are in the email under ArgoCD Deployments. Make sure you get the right “datacenter one - there is another one for OpenShift gitops which could be confusing. It should look like this:
+Demo: Configuration Changes with GitOps Follow the procedures here
+Demo: Application Changes with DevOps Follow the procedures here
+Demo: Application AI Model Changes with DevOps Follow the procedures here
+Troubleshooting If you run into any problems, checkout the potential/Known issues list: http://validatedpatterns.io/industrial-edge/troubleshooting/
+Summary In this demo we: , we show you how to get started with the Industrial Edge Validated Pattern. In
+Show you how to get started with the Industrial Edge Pattern Make configuration changes with GitOps Make application changes with DevOps Use DevOps to make changes to an Application AI model Stream events from the edge to the datacenter `,url:"https://validatedpatterns.io/patterns/industrial-edge/demo-script/",breadcrumb:"/patterns/industrial-edge/demo-script/"},"https://validatedpatterns.io/ci/":{title:"CI Status",tags:[],content:`These are the latest results of the Validated Patterns CI test runs.
+Note Note Industrial Edge is known to be broken on 4.14 due to an unavailable dependency. `,url:"https://validatedpatterns.io/ci/",breadcrumb:"/ci/"},"https://validatedpatterns.io/patterns/cockroachdb/":{title:"Cockroach",tags:[],content:`Cockroach A multicloud pattern using cockroachdb and submariner, deployed via RHACM.
+Repo
+`,url:"https://validatedpatterns.io/patterns/cockroachdb/",breadcrumb:"/patterns/cockroachdb/"},"https://validatedpatterns.io/patterns/connected-vehicle-architecture/":{title:"Connected Vehicle Architecture",tags:[],content:`Connected Vehicle Architecture A distributed cloud-native application that implements key aspects of a modern IoT architecture.
+Repo
+`,url:"https://validatedpatterns.io/patterns/connected-vehicle-architecture/",breadcrumb:"/patterns/connected-vehicle-architecture/"},"https://validatedpatterns.io/contribute/":{title:"Contribute to Validated Patterns",tags:[],content:` Find out how you can contribute to the Validated Patterns project.
+`,url:"https://validatedpatterns.io/contribute/",breadcrumb:"/contribute/"},"https://validatedpatterns.io/ci/internal/":{title:"Internal CI Status",tags:[],content:`These are the latest results of the Validated Patterns CI test runs. The links on this page are internal Red Hat links and require a valid Red Hat login to access them.
+`,url:"https://validatedpatterns.io/ci/internal/",breadcrumb:"/ci/internal/"},"https://validatedpatterns.io/patterns/kong-gateway/":{title:"Kong",tags:[],content:`Kong A pattern for Kong Gateway Control Plane and Data Plane demo
+Repo
+`,url:"https://validatedpatterns.io/patterns/kong-gateway/",breadcrumb:"/patterns/kong-gateway/"},"https://validatedpatterns.io/learn/":{title:"Learn about Validated Patterns",tags:[],content:` Find out more information about Validated Patterns and how they work.
+`,url:"https://validatedpatterns.io/learn/",breadcrumb:"/learn/"},"https://validatedpatterns.io/patterns/multicloud-gitops-portworx/":{title:"Multicloud GitOps with Portworx Enterprise",tags:[],content:`Multicloud GitOps with Portworx Enterprise Some details will differ based on the requirements of a specific implementation but all validated patterns, based on a portfolio architecture, generalize one or more successful deployments of a use case.
+Use case:
+Use a GitOps approach to manage hybrid and multi-cloud deployments across both public and private clouds. Enable cross-cluster governance and application lifecycle management. Securely manage secrets across the deployment. Deploy and configure Portworx Enterprise persistent storage for stateful applications. Background: Organizations are aiming to develop, deploy, and operate applications on an open hybrid cloud in a stable, simple, and secure way. This hybrid strategy includes multi-cloud deployments where workloads might be running on multiple clusters and on multiple clouds—private or public. It include Portworx Enterprise for persistent storage and Kubernetes data services required for stateful applications.
+This strategy requires an infrastructure-as-code approach: GitOps. GitOps uses Git repositories as a single source of truth to deliver infrastructure-as-code. Submitted code will be checked by the continuous integration (CI) process, while the continuous delivery (CD) process checks and applies requirements for things like security, infrastructure-as-code, or any other boundaries set for the application framework. All changes to code are tracked, making updates easy while also providing version control should a rollback be needed.
+Solution overview This architecture covers hybrid and multi-cloud management with GitOps as shown in Figure 1. At a high level this requires a management hub, for DevOps and GitOps, and infrastructure that extends to one or more managed clusters running on private or public clouds. The automated infrastructure-as-code approach can manage the versioning of components and deploy according to the infrastructure-as-code configuration.
+Why Hybrid Multicloud management with GitOps ?
+Unify management across cloud environments. Dynamic infrastructure security. Infrastructural continuous delivery best practices. Figure 1 shows a high-level overview of the solution including the business drivers, management hub, and the clusters under management.
+Logical diagram Figure 2. Logical diagram of hybrid multi-cloud management with GitOps.
+As you can see in Figure 2, logically this solution can be viewed as being composed of an automation component, unified management (including secrets management), and the cluster(s) under management—all running on top of a user-chosen mixture of on-prem data center(s) and public cloud(s).
+The technology The following technology was chosen for this solution.
+Red Hat OpenShift Platform is an enterprise-ready Kubernetes container platform built for an open hybrid cloud strategy. It provides a consistent application platform to manage hybrid cloud, public cloud, and edge deployments. It delivers a complete application platform for both traditional and cloud-native applications, allowing them to run anywhere. OpenShift has a pre-configured, pre-installed, and self-updating monitoring stack that provides monitoring for core platform components. It also enables the use of external secret management systems (like HashiCorp Vault in this case) to securely add secrets into the OpenShift platform.
+Red Hat OpenShift GitOps is a declarative application continuous delivery tool for Kubernetes based on the ArgoCD project. Application definitions, configurations, and environments are declarative and version controlled in Git. It can automatically push the desired application state into a cluster, quickly find out if the application state is in sync with the desired state, and manage applications in multi-cluster environments.
+Red Hat Advanced Cluster Management for Kubernetes controls clusters and applications from a single console, with built-in security policies. Extends the value of Red Hat OpenShift by deploying apps, managing multiple clusters, and enforcing policies across multiple clusters at scale.
+Red Hat Ansible Automation Platform provides an enterprise framework for building and operating IT automation at scale across hybrid clouds including edge deployments. It enables users across an organization to create, share, and manage automation—from development and operations to security and network teams.
+Portworx Enterprise provides persistent storage and Kubernetes data services to Red Hat OpenShift. Persistence is necessary for stateful applications in Kubernetes environments. Portworx also provides business continuity with Portworx Backup and Portworx DR products that will be incorporated in a future GitOps pattern.
+Hashicorp Vault provides a secure centralized store for dynamic infrastructure and applications across clusters, including over low-trust networks between clouds and data centers.
+This solution also uses a variety of observability tools including the Prometheus monitoring and Grafana dashboard that are integrated with OpenShift as well as components of the Observatorium meta-project which includes Thanos and the Loki API.
+Architectures Figure 3 provides a schematic diagram overview of the complete solution including both components and data flows.
+Subsequent schematic diagrams go into more detail on:
+Bootstrapping the management hub (Figure 4) Hybrid multi-cloud GitOps (Figure 5) Dynamic security management (Figure 6) Observability in hybrid multi-cloud environments (Figure 7) Figure 3. Overview schematic diagram of the complete solution.
+Bootstrapping the management hub Figure 4. Schematic diagram of bootstrapping the management hub.
+As detailed below, Figure 4 provides a schematic diagram showing the setup of the management hub using Ansible playbooks.
+Set up the Red Hat OpenShift Platform that hosts the Management Hub. The OpenShift installation program provides flexible ways to install OpenShift. An Ansible playbook kicks off the installation with necessary configurations. Ansible playbooks are again used to deploy and configure Red Hat Advanced Cluster Management for Kubernetes and, later, other supporting components (such as external secrets management) on top of the provisioned OpenShift cluster. Another Ansible playbook installs HashiCorp Vault, a Red Hat partner product chosen for this solution that can be used to manage secrets for OpenShift clusters. An Ansible playbook is used again to configure and trigger the Openshift GitOps operator on the hub cluster. This deploys the Openshift GitOps instance to enable continuous delivery. Hybrid multicloud GitOps Figure 5. Schematic diagram of hybrid multi-cloud management with GitOps.
+As detailed below, Figure 5 provides a schematic diagram showing remaining activities associated with setting up the management hub and clusters using Red Hat Advanced Cluster Management.
+Manifest and configuration are set as code template in the form of “Kustomization” yaml. It describes the end desire state of how the managed cluster is going to be like. When done, it is pushed into the source control management repository with a version assigned to each update. OpenShift GitOps watches the repository and detects changes in the repository. OpenShift GitOps creates/updates the manifest by creating Kubernetes objects on top of Red Hat Advanced Cluster Management. Red Hat Advanced Cluster Management provision/update/delete managed clusters and configuration according to the manifest. In the manifest, you can configure what cloud provider the cluster will be on, the name of the cluster, infra node details and worker node. Governance policy can also be applied as well as provision an agent in the cluster as the bridge between the control center and the managed cluster. OpenShift GitOps will continuously watch between the code repository and status of the clusters reported back to Red Hat Advanced Cluster Management. Any configuration drift or in case of any failure, it will automatically try to remediate by applying the manifest (Or showing alerts for manual intervention). Dynamic security management Figure 6. Schematic showing the setup and use of external secrets management.
+As detailed below, Figure 6 provides a schematic diagram showing how secrets are handled in this solution.
+During setup, the token to securely access HashiCorp Vault is stored in Ansible Vault. It is encrypted to protect sensitive content.
+Red Hat Advanced Cluster Management for Kubernetes allows us to have centralized control over the managed clusters. It acquires the token from Ansible Vault during install and distributes it among the clusters.
+To allow the cluster access to the external vault, we need to set up the external secret management (with Helm in this study). OpenShift Gitops is used to deploy the external secret object to a managed cluster.
+External secret management fetches secrets from HashiCorp Vault using the token we created in step 2 and constantly watches for updates. Secrets are created in each namespace, where applications can use them.
+Demo Scenario Download diagrams View and download all of the diagrams above in our open source tooling site.
+[Open Diagrams]
+What Next Deploy the management hub using Helm Add a managed cluster to deploy the managed cluster piece using ACM `,url:"https://validatedpatterns.io/patterns/multicloud-gitops-portworx/",breadcrumb:"/patterns/multicloud-gitops-portworx/"},"https://validatedpatterns.io/contribute/support-policies/":{title:"Support Policies",tags:[],content:` Purpose The purpose of this support policy is to define expectations for the time in which consumers and developers of the Patterns framework can expect to receive assistance with their query to the Validated Patterns team.
+Continuous Integration (CI) Failures Expected Response time: 5 business days
+The Validated Patterns team will collectively triage any CI failures for patterns to which this policy applies each Monday. If necessary, a Jira issue will be created and tracked by the team.
+Reporting Pattern Issues Normally there is a path to support all products within a pattern. Either they are directly supported by the vendor (of which Red Hat may be one), or an enterprise version of that product exists.
+All product issues should be directed to the vendor of that product.
+For problems deploying patterns, unhealthy GitOps applications, or broken demos, please create an issue within the pattern’s github repository where they will be reviewed by the appropriate SME.
+To ensure we can best help you please provide the following information:
+Environment Details (Machine Sizes, Specialized Network, Storage, Hardware)
+The output of the error
+Any changes that were made prior to the failure
+Expected Outcome: What you thought should have happened
+If you are unsure if your issue is product or pattern related, please reach out to the community using https://groups.google.com/g/validatedpatterns or by emailing validatedpatterns@googlegroups.com
+Any pattern-based security issues, such as hard coded secrets, found should be reported to: validated-patterns-team@redhat.com You can expect a response within 5 business days
+Pull Requests Pull Requests against Patterns to which this policy applies will be reviewed by the appropriate SME or by the patterns team. We will endeavor to provide initial feedback within 10 business days, but ask for patience during busy periods, or if we happen to be on vacation.
+Feature Enhancements Create an issue, use the enhancement label, be clear what the desired functionality is and why it is necessary. For enhancements that could or should apply across multiple patterns, please file them against common. Use the following as a guide for creating your feature request:
+Proposed title of the feature request
+What is the nature and description of the request?
+Why do you need / want this? (List business requirements here)
+List any affected packages or components
+`,url:"https://validatedpatterns.io/contribute/support-policies/",breadcrumb:"/contribute/support-policies/"}}</script><script src=/js/lunr.js></script><script src=/js/search.js></script></footer></main></div><script src=/js/codeblock.js></script></body></html>
\ No newline at end of file
diff --git a/patterns/regional-dr/index.xml b/patterns/regional-dr/index.xml
new file mode 100644
index 000000000..e75046cba
--- /dev/null
+++ b/patterns/regional-dr/index.xml
@@ -0,0 +1 @@
+<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Regional Disaster Recovery on Validated Patterns</title><link>https://validatedpatterns.io/patterns/regional-dr/</link><description>Recent content in Regional Disaster Recovery on Validated Patterns</description><generator>Hugo</generator><language>en-us</language><lastBuildDate/><atom:link href="https://validatedpatterns.io/patterns/regional-dr/index.xml" rel="self" type="application/rss+xml"/></channel></rss>
\ No newline at end of file
diff --git a/patterns/retail/application/index.html b/patterns/retail/application/index.html
index b9bed5b4f..41231f2b0 100644
--- a/patterns/retail/application/index.html
+++ b/patterns/retail/application/index.html
@@ -3738,7 +3738,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/retail/cluster-sizing/index.html b/patterns/retail/cluster-sizing/index.html
index 1b4264a5a..5b0079f14 100644
--- a/patterns/retail/cluster-sizing/index.html
+++ b/patterns/retail/cluster-sizing/index.html
@@ -3740,7 +3740,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/retail/components/index.html b/patterns/retail/components/index.html
index 9c5cde514..c4caeb36c 100644
--- a/patterns/retail/components/index.html
+++ b/patterns/retail/components/index.html
@@ -3738,7 +3738,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/retail/getting-started/index.html b/patterns/retail/getting-started/index.html
index f569335c2..31f06e87f 100644
--- a/patterns/retail/getting-started/index.html
+++ b/patterns/retail/getting-started/index.html
@@ -3758,7 +3758,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/retail/ideas-for-customization/index.html b/patterns/retail/ideas-for-customization/index.html
index 5bb3546a6..53851e365 100644
--- a/patterns/retail/ideas-for-customization/index.html
+++ b/patterns/retail/ideas-for-customization/index.html
@@ -3738,7 +3738,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/retail/index.html b/patterns/retail/index.html
index dba0de7a3..238d2961f 100644
--- a/patterns/retail/index.html
+++ b/patterns/retail/index.html
@@ -3744,7 +3744,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/retail/store/index.html b/patterns/retail/store/index.html
index 8b1cc5481..95b61b920 100644
--- a/patterns/retail/store/index.html
+++ b/patterns/retail/store/index.html
@@ -3753,7 +3753,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/retail/troubleshooting/index.html b/patterns/retail/troubleshooting/index.html
index 50f0584c5..f1247379a 100644
--- a/patterns/retail/troubleshooting/index.html
+++ b/patterns/retail/troubleshooting/index.html
@@ -3738,7 +3738,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/travelops/demo-script/index.html b/patterns/travelops/demo-script/index.html
index b61383851..dc80c9109 100644
--- a/patterns/travelops/demo-script/index.html
+++ b/patterns/travelops/demo-script/index.html
@@ -3738,7 +3738,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/travelops/getting-started/index.html b/patterns/travelops/getting-started/index.html
index b383533a1..6fa3aff3b 100644
--- a/patterns/travelops/getting-started/index.html
+++ b/patterns/travelops/getting-started/index.html
@@ -3762,7 +3762,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/travelops/ideas-for-customization/index.html b/patterns/travelops/ideas-for-customization/index.html
index c6f18161c..ee103b27a 100644
--- a/patterns/travelops/ideas-for-customization/index.html
+++ b/patterns/travelops/ideas-for-customization/index.html
@@ -3738,7 +3738,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/patterns/travelops/index.html b/patterns/travelops/index.html
index 24b4369a9..684ae5889 100644
--- a/patterns/travelops/index.html
+++ b/patterns/travelops/index.html
@@ -3743,7 +3743,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/rh_products/red-hat-openshift-container-platform/index.html b/rh_products/red-hat-openshift-container-platform/index.html
index cfa655af6..6362b5cba 100644
--- a/rh_products/red-hat-openshift-container-platform/index.html
+++ b/rh_products/red-hat-openshift-container-platform/index.html
@@ -1,3 +1,3 @@
 <!doctype html><html><head><link rel=stylesheet href=https://validatedpatterns.io/sass/patternfly.css><link rel=stylesheet href=/css/custom.css><link rel=stylesheet href=https://validatedpatterns.io/sass/patternfly-addons.css><link rel=stylesheet href=https://use.fontawesome.com/releases/v6.3.0/css/solid.css><link rel=stylesheet href=https://use.fontawesome.com/releases/v6.3.0/css/fontawesome.css><link rel=stylesheet href=https://use.fontawesome.com/releases/v6.3.0/css/brands.css><title>Red Hat OpenShift Container Platform | Validated Patterns</title></head><body><div class=pf-c-page><header class=pf-c-page__header><div class=pf-c-page__header-brand><a href=/ class=pf-c-page__header-brand-link><img src=/images/validated-patterns.png alt="Validated Patterns"></a></div><div class=pf-c-page__header-tools><nav class="pf-c-nav pf-m-horizontal" role=navigation><ul class=pf-c-nav__list><li class=pf-c-nav__item><a class=pf-c-nav__link href=/patterns/ title=Patterns>Patterns</a></li><li class=pf-c-nav__item><a class=pf-c-nav__link href=/learn/ title="Learn about Validated Patterns">Learn</a></li><li class=pf-c-nav__item><a class=pf-c-nav__link href=https://play.validatedpatterns.io title>Workshop</a></li><li class=pf-c-nav__item><a class=pf-c-nav__link href=/contribute/ title="Contribute to Validated Patterns">Contribute</a></li><li class=pf-c-nav__item><a class=pf-c-nav__link href=/blog/ title=Blog>Blog</a></li><li class=pf-c-nav__item><a class=pf-c-nav__link href=/ci/ title="CI Status">Status</a></li></ul></nav><form id=search action=https://validatedpatterns.io/search/ method=get><div class=pf-c-search-input><div class=pf-c-input-group><div class=pf-c-search-input__bar><span class=pf-c-search-input__text><span class=pf-c-search-input__icon><i class="fas fa-search fa-fw" aria-hidden=true></i>
 </span><input id=search-input name=query class=pf-c-search-input__text-input type=text placeholder=Search aria-label=Search></span></div><button form=search class="pf-c-button pf-m-control" type=submit aria-label=Search value=search>
-<i class="fas fa-arrow-right" aria-hidden=true></i></button></div></div></form></div></header><main class=pf-c-page__main><section class=pf-c-page__main-section><div class=pf-l-stack><div class=pf-c-content style=--pf-c-content--FontSize:1.25rem></div></div></section><div><div><div class=pf-c-card style=text-align:left><div class=pf-c-card__title><h1><a href=/patterns/ansible-edge-gitops-kasten/>Ansible Edge GitOps with Veeam Kasten</a></h1></div><div class=pf-c-card__body>This pattern uses OpenShift Virtualization to simulate an edge environment for VMs, protected by Veeam Kasten.</div><div class=pf-c-card__footer><a href=/patterns/ansible-edge-gitops-kasten/></a></div></div></div><div><div class=pf-c-card style=text-align:left><div class=pf-c-card__title><h1><a href=/patterns/coco-pattern/>Confidential Containers pattern</a></h1></div><div class=pf-c-card__body>This pattern helps you get started with deploying confidential containers in OpenShift Container Platform.</div><div class=pf-c-card__footer><a href=/patterns/coco-pattern/></a></div></div></div><div><div class=pf-c-card style=text-align:left><div class=pf-c-card__title><h1><a href=/patterns/rag-llm-gitops/>AI Generation with LLM and RAG</a></h1></div><div class=pf-c-card__body>The goal of this demo is to demonstrate a Chatbot LLM application augmented with data from Red Hat product documentation running on Red Hat OpenShift. It deploys an LLM application that connects to multiple LLM providers such as OpenAI, Hugging Face, and NVIDIA NIM. The application generates a project proposal for a Red Hat product.</div><div class=pf-c-card__footer><a href=/patterns/rag-llm-gitops/></a></div></div></div><div><div class=pf-c-card style=text-align:left><div class=pf-c-card__title><h1><a href=/patterns/gaudi-rag-chat-qna/>OPEA QnA chat accelerated with Intel Gaudi</a></h1></div><div class=pf-c-card__body>This pattern helps you deploy stack enabling Intel Gaudi Accelerator and it also deploys RAG application - Chat QnA</div><div class=pf-c-card__footer><a href=/patterns/gaudi-rag-chat-qna/></a></div></div></div><div><div class=pf-c-card style=text-align:left><div class=pf-c-card__title><h1><a href=/patterns/openshift-ai/>OpenShift AI</a></h1></div><div class=pf-c-card__body>This pattern is a starting point for using Red Hat OpenShift AI.</div><div class=pf-c-card__footer><a href=/patterns/openshift-ai/></a></div></div></div><div><div class=pf-c-card style=text-align:left><div class=pf-c-card__title><h1><a href=/patterns/travelops/>TravelOps</a></h1></div><div class=pf-c-card__body>This pattern enables you to secure your applications using Red Hat Service Mesh.</div><div class=pf-c-card__footer><a href=/patterns/travelops/></a></div></div></div><ul class="pagination pagination-default"><li class="page-item disabled"><a aria-disabled=true aria-label=First class=page-link role=button tabindex=-1><span aria-hidden=true>&#171;&#171;</span></a></li><li class="page-item disabled"><a aria-disabled=true aria-label=Previous class=page-link role=button tabindex=-1><span aria-hidden=true>&#171;</span></a></li><li class="page-item active"><a aria-current=page aria-label="Page 1" class=page-link role=button>1</a></li><li class=page-item><a href=/rh_products/red-hat-openshift-container-platform/page/2/ aria-label="Page 2" class=page-link role=button>2</a></li><li class=page-item><a href=/rh_products/red-hat-openshift-container-platform/page/3/ aria-label="Page 3" class=page-link role=button>3</a></li><li class=page-item><a href=/rh_products/red-hat-openshift-container-platform/page/4/ aria-label="Page 4" class=page-link role=button>4</a></li><li class=page-item><a href=/rh_products/red-hat-openshift-container-platform/page/2/ aria-label=Next class=page-link role=button><span aria-hidden=true>&#187;</span></a></li><li class=page-item><a href=/rh_products/red-hat-openshift-container-platform/page/4/ aria-label=Last class=page-link role=button><span aria-hidden=true>&#187;&#187;</span></a></li></ul></div></main></div><script src=/js/codeblock.js></script></body></html>
\ No newline at end of file
+<i class="fas fa-arrow-right" aria-hidden=true></i></button></div></div></form></div></header><main class=pf-c-page__main><section class=pf-c-page__main-section><div class=pf-l-stack><div class=pf-c-content style=--pf-c-content--FontSize:1.25rem></div></div></section><div><div><div class=pf-c-card style=text-align:left><div class=pf-c-card__title><h1><a href=/patterns/ansible-edge-gitops-kasten/>Ansible Edge GitOps with Veeam Kasten</a></h1></div><div class=pf-c-card__body>This pattern uses OpenShift Virtualization to simulate an edge environment for VMs, protected by Veeam Kasten.</div><div class=pf-c-card__footer><a href=/patterns/ansible-edge-gitops-kasten/></a></div></div></div><div><div class=pf-c-card style=text-align:left><div class=pf-c-card__title><h1><a href=/patterns/coco-pattern/>Confidential Containers pattern</a></h1></div><div class=pf-c-card__body>This pattern helps you get started with deploying confidential containers in OpenShift Container Platform.</div><div class=pf-c-card__footer><a href=/patterns/coco-pattern/></a></div></div></div><div><div class=pf-c-card style=text-align:left><div class=pf-c-card__title><h1><a href=/patterns/regional-dr/>Regional Disaster Recovery</a></h1></div><div class=pf-c-card__body>This variant of the Validated Patterns framework deploys a Regional Disaster Recovery Setup across multiple different regions</div><div class=pf-c-card__footer><a href=/patterns/regional-dr/></a></div></div></div><div><div class=pf-c-card style=text-align:left><div class=pf-c-card__title><h1><a href=/patterns/rag-llm-gitops/>AI Generation with LLM and RAG</a></h1></div><div class=pf-c-card__body>The goal of this demo is to demonstrate a Chatbot LLM application augmented with data from Red Hat product documentation running on Red Hat OpenShift. It deploys an LLM application that connects to multiple LLM providers such as OpenAI, Hugging Face, and NVIDIA NIM. The application generates a project proposal for a Red Hat product.</div><div class=pf-c-card__footer><a href=/patterns/rag-llm-gitops/></a></div></div></div><div><div class=pf-c-card style=text-align:left><div class=pf-c-card__title><h1><a href=/patterns/gaudi-rag-chat-qna/>OPEA QnA chat accelerated with Intel Gaudi</a></h1></div><div class=pf-c-card__body>This pattern helps you deploy stack enabling Intel Gaudi Accelerator and it also deploys RAG application - Chat QnA</div><div class=pf-c-card__footer><a href=/patterns/gaudi-rag-chat-qna/></a></div></div></div><div><div class=pf-c-card style=text-align:left><div class=pf-c-card__title><h1><a href=/patterns/openshift-ai/>OpenShift AI</a></h1></div><div class=pf-c-card__body>This pattern is a starting point for using Red Hat OpenShift AI.</div><div class=pf-c-card__footer><a href=/patterns/openshift-ai/></a></div></div></div><ul class="pagination pagination-default"><li class="page-item disabled"><a aria-disabled=true aria-label=First class=page-link role=button tabindex=-1><span aria-hidden=true>&#171;&#171;</span></a></li><li class="page-item disabled"><a aria-disabled=true aria-label=Previous class=page-link role=button tabindex=-1><span aria-hidden=true>&#171;</span></a></li><li class="page-item active"><a aria-current=page aria-label="Page 1" class=page-link role=button>1</a></li><li class=page-item><a href=/rh_products/red-hat-openshift-container-platform/page/2/ aria-label="Page 2" class=page-link role=button>2</a></li><li class=page-item><a href=/rh_products/red-hat-openshift-container-platform/page/3/ aria-label="Page 3" class=page-link role=button>3</a></li><li class=page-item><a href=/rh_products/red-hat-openshift-container-platform/page/4/ aria-label="Page 4" class=page-link role=button>4</a></li><li class=page-item><a href=/rh_products/red-hat-openshift-container-platform/page/2/ aria-label=Next class=page-link role=button><span aria-hidden=true>&#187;</span></a></li><li class=page-item><a href=/rh_products/red-hat-openshift-container-platform/page/4/ aria-label=Last class=page-link role=button><span aria-hidden=true>&#187;&#187;</span></a></li></ul></div></main></div><script src=/js/codeblock.js></script></body></html>
\ No newline at end of file
diff --git a/rh_products/red-hat-openshift-container-platform/index.xml b/rh_products/red-hat-openshift-container-platform/index.xml
index 0339b4bc2..7b609cf11 100644
--- a/rh_products/red-hat-openshift-container-platform/index.xml
+++ b/rh_products/red-hat-openshift-container-platform/index.xml
@@ -1 +1 @@
-<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Red Hat OpenShift Container Platform on Validated Patterns</title><link>https://validatedpatterns.io/rh_products/red-hat-openshift-container-platform/</link><description>Recent content in Red Hat OpenShift Container Platform on Validated Patterns</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Mon, 28 Oct 2024 00:00:00 +0000</lastBuildDate><atom:link href="https://validatedpatterns.io/rh_products/red-hat-openshift-container-platform/index.xml" rel="self" type="application/rss+xml"/><item><title>Ansible Edge GitOps with Veeam Kasten</title><link>https://validatedpatterns.io/patterns/ansible-edge-gitops-kasten/</link><pubDate>Mon, 28 Oct 2024 00:00:00 +0000</pubDate><guid>https://validatedpatterns.io/patterns/ansible-edge-gitops-kasten/</guid><description>This pattern uses OpenShift Virtualization to simulate an edge environment for VMs, protected by Veeam Kasten.</description></item><item><title>Confidential Containers pattern</title><link>https://validatedpatterns.io/patterns/coco-pattern/</link><pubDate>Thu, 03 Oct 2024 00:00:00 +0000</pubDate><guid>https://validatedpatterns.io/patterns/coco-pattern/</guid><description>This pattern helps you get started with deploying confidential containers in OpenShift Container Platform.</description></item><item><title>AI Generation with LLM and RAG</title><link>https://validatedpatterns.io/patterns/rag-llm-gitops/</link><pubDate>Thu, 25 Jul 2024 00:00:00 +0000</pubDate><guid>https://validatedpatterns.io/patterns/rag-llm-gitops/</guid><description>The goal of this demo is to demonstrate a Chatbot LLM application augmented with data from Red Hat product documentation running on Red Hat OpenShift. It deploys an LLM application that connects to multiple LLM providers such as OpenAI, Hugging Face, and NVIDIA NIM. The application generates a project proposal for a Red Hat product.</description></item><item><title>OPEA QnA chat accelerated with Intel Gaudi</title><link>https://validatedpatterns.io/patterns/gaudi-rag-chat-qna/</link><pubDate>Sat, 01 Jun 2024 00:00:00 +0000</pubDate><guid>https://validatedpatterns.io/patterns/gaudi-rag-chat-qna/</guid><description>This pattern helps you deploy stack enabling Intel Gaudi Accelerator and it also deploys RAG application - Chat QnA</description></item><item><title>OpenShift AI</title><link>https://validatedpatterns.io/patterns/openshift-ai/</link><pubDate>Mon, 22 Apr 2024 00:00:00 +0000</pubDate><guid>https://validatedpatterns.io/patterns/openshift-ai/</guid><description>This pattern is a starting point for using Red Hat OpenShift AI.</description></item><item><title>TravelOps</title><link>https://validatedpatterns.io/patterns/travelops/</link><pubDate>Fri, 09 Feb 2024 00:00:00 +0000</pubDate><guid>https://validatedpatterns.io/patterns/travelops/</guid><description>This pattern enables you to secure your applications using Red Hat Service Mesh.</description></item><item><title>HyperShift</title><link>https://validatedpatterns.io/patterns/hypershift/</link><pubDate>Wed, 15 Nov 2023 00:00:00 +0000</pubDate><guid>https://validatedpatterns.io/patterns/hypershift/</guid><description>This pattern is for deploying the Hosted Control Plane (HyperShift) service.</description></item><item><title>MLOps Fraud Detection</title><link>https://validatedpatterns.io/patterns/mlops-fraud-detection/</link><pubDate>Sun, 12 Nov 2023 00:00:00 +0000</pubDate><guid>https://validatedpatterns.io/patterns/mlops-fraud-detection/</guid><description>This pattern demonstrates how Red Hat OpenShift Data Science and MLFlow can be used together to build an end-to-end MLOps platform. It demonstrates this using a credit card fraud detection use case.</description></item><item><title>Emerging Disease Detection</title><link>https://validatedpatterns.io/patterns/emerging-disease-detection/</link><pubDate>Sat, 23 Sep 2023 00:00:00 +0000</pubDate><guid>https://validatedpatterns.io/patterns/emerging-disease-detection/</guid><description>This pattern is based on a demo implementation of an automated data pipeline for sepsis analysis previously developed by Red Hat.</description></item><item><title>Retail</title><link>https://validatedpatterns.io/patterns/retail/</link><pubDate>Thu, 08 Dec 2022 00:00:00 +0000</pubDate><guid>https://validatedpatterns.io/patterns/retail/</guid><description>This pattern demonstrates a pattern that models the store side of a retail application.</description></item><item><title>Ansible Edge GitOps</title><link>https://validatedpatterns.io/patterns/ansible-edge-gitops/</link><pubDate>Wed, 08 Jun 2022 00:00:00 +0000</pubDate><guid>https://validatedpatterns.io/patterns/ansible-edge-gitops/</guid><description>This pattern uses OpenShift Virtualization to simulate an edge environment for VMs.</description></item><item><title>Multicluster DevSecOps</title><link>https://validatedpatterns.io/patterns/devsecops/</link><pubDate>Wed, 08 Jun 2022 00:00:00 +0000</pubDate><guid>https://validatedpatterns.io/patterns/devsecops/</guid><description>This pattern is derived from the multi-cloud GitOps pattern with added products to provide a complete DevSecOps workflow.</description></item><item><title>Multicloud GitOps</title><link>https://validatedpatterns.io/patterns/multicloud-gitops/</link><pubDate>Sat, 11 Dec 2021 00:00:00 +0000</pubDate><guid>https://validatedpatterns.io/patterns/multicloud-gitops/</guid><description>This pattern helps you develop and deploy applications on an open hybrid cloud in a stable, simple, and secure way.</description></item><item><title>Industrial Edge</title><link>https://validatedpatterns.io/patterns/industrial-edge/</link><pubDate>Tue, 12 Oct 2021 00:00:00 +0000</pubDate><guid>https://validatedpatterns.io/patterns/industrial-edge/</guid><description>This pattern demonstrates a horizontal solution for Industrial Edge use cases.</description></item><item><title>Medical Diagnosis</title><link>https://validatedpatterns.io/patterns/medical-diagnosis/</link><pubDate>Tue, 19 Jan 2021 00:00:00 +0000</pubDate><guid>https://validatedpatterns.io/patterns/medical-diagnosis/</guid><description>This pattern is based on a demo implementation of an automated data pipeline for chest X-ray analysis previously developed by Red Hat.</description></item><item><title>Cockroach</title><link>https://validatedpatterns.io/patterns/cockroachdb/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://validatedpatterns.io/patterns/cockroachdb/</guid><description>A multicloud pattern using cockroachdb and submariner, deployed via RHACM.</description></item><item><title>Connected Vehicle Architecture</title><link>https://validatedpatterns.io/patterns/connected-vehicle-architecture/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://validatedpatterns.io/patterns/connected-vehicle-architecture/</guid><description>A distributed cloud-native application that implements key aspects of a modern IoT architecture.</description></item><item><title>Kong</title><link>https://validatedpatterns.io/patterns/kong-gateway/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://validatedpatterns.io/patterns/kong-gateway/</guid><description>A pattern for Kong Gateway Control Plane and Data Plane demo.</description></item><item><title>Multicloud GitOps with Portworx Enterprise</title><link>https://validatedpatterns.io/patterns/multicloud-gitops-portworx/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://validatedpatterns.io/patterns/multicloud-gitops-portworx/</guid><description>This pattern helps you develop and deploy applications on an open hybrid cloud in a stable, simple, and secure way. It includes persistent storage for stateful applications.</description></item></channel></rss>
\ No newline at end of file
+<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Red Hat OpenShift Container Platform on Validated Patterns</title><link>https://validatedpatterns.io/rh_products/red-hat-openshift-container-platform/</link><description>Recent content in Red Hat OpenShift Container Platform on Validated Patterns</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Mon, 28 Oct 2024 00:00:00 +0000</lastBuildDate><atom:link href="https://validatedpatterns.io/rh_products/red-hat-openshift-container-platform/index.xml" rel="self" type="application/rss+xml"/><item><title>Ansible Edge GitOps with Veeam Kasten</title><link>https://validatedpatterns.io/patterns/ansible-edge-gitops-kasten/</link><pubDate>Mon, 28 Oct 2024 00:00:00 +0000</pubDate><guid>https://validatedpatterns.io/patterns/ansible-edge-gitops-kasten/</guid><description>This pattern uses OpenShift Virtualization to simulate an edge environment for VMs, protected by Veeam Kasten.</description></item><item><title>Confidential Containers pattern</title><link>https://validatedpatterns.io/patterns/coco-pattern/</link><pubDate>Thu, 03 Oct 2024 00:00:00 +0000</pubDate><guid>https://validatedpatterns.io/patterns/coco-pattern/</guid><description>This pattern helps you get started with deploying confidential containers in OpenShift Container Platform.</description></item><item><title>Regional Disaster Recovery</title><link>https://validatedpatterns.io/patterns/regional-dr/</link><pubDate>Fri, 20 Sep 2024 00:00:00 +0000</pubDate><guid>https://validatedpatterns.io/patterns/regional-dr/</guid><description>This variant of the Validated Patterns framework deploys a Regional Disaster Recovery Setup across multiple different regions</description></item><item><title>AI Generation with LLM and RAG</title><link>https://validatedpatterns.io/patterns/rag-llm-gitops/</link><pubDate>Thu, 25 Jul 2024 00:00:00 +0000</pubDate><guid>https://validatedpatterns.io/patterns/rag-llm-gitops/</guid><description>The goal of this demo is to demonstrate a Chatbot LLM application augmented with data from Red Hat product documentation running on Red Hat OpenShift. It deploys an LLM application that connects to multiple LLM providers such as OpenAI, Hugging Face, and NVIDIA NIM. The application generates a project proposal for a Red Hat product.</description></item><item><title>OPEA QnA chat accelerated with Intel Gaudi</title><link>https://validatedpatterns.io/patterns/gaudi-rag-chat-qna/</link><pubDate>Sat, 01 Jun 2024 00:00:00 +0000</pubDate><guid>https://validatedpatterns.io/patterns/gaudi-rag-chat-qna/</guid><description>This pattern helps you deploy stack enabling Intel Gaudi Accelerator and it also deploys RAG application - Chat QnA</description></item><item><title>OpenShift AI</title><link>https://validatedpatterns.io/patterns/openshift-ai/</link><pubDate>Mon, 22 Apr 2024 00:00:00 +0000</pubDate><guid>https://validatedpatterns.io/patterns/openshift-ai/</guid><description>This pattern is a starting point for using Red Hat OpenShift AI.</description></item><item><title>TravelOps</title><link>https://validatedpatterns.io/patterns/travelops/</link><pubDate>Fri, 09 Feb 2024 00:00:00 +0000</pubDate><guid>https://validatedpatterns.io/patterns/travelops/</guid><description>This pattern enables you to secure your applications using Red Hat Service Mesh.</description></item><item><title>HyperShift</title><link>https://validatedpatterns.io/patterns/hypershift/</link><pubDate>Wed, 15 Nov 2023 00:00:00 +0000</pubDate><guid>https://validatedpatterns.io/patterns/hypershift/</guid><description>This pattern is for deploying the Hosted Control Plane (HyperShift) service.</description></item><item><title>MLOps Fraud Detection</title><link>https://validatedpatterns.io/patterns/mlops-fraud-detection/</link><pubDate>Sun, 12 Nov 2023 00:00:00 +0000</pubDate><guid>https://validatedpatterns.io/patterns/mlops-fraud-detection/</guid><description>This pattern demonstrates how Red Hat OpenShift Data Science and MLFlow can be used together to build an end-to-end MLOps platform. It demonstrates this using a credit card fraud detection use case.</description></item><item><title>Emerging Disease Detection</title><link>https://validatedpatterns.io/patterns/emerging-disease-detection/</link><pubDate>Sat, 23 Sep 2023 00:00:00 +0000</pubDate><guid>https://validatedpatterns.io/patterns/emerging-disease-detection/</guid><description>This pattern is based on a demo implementation of an automated data pipeline for sepsis analysis previously developed by Red Hat.</description></item><item><title>Retail</title><link>https://validatedpatterns.io/patterns/retail/</link><pubDate>Thu, 08 Dec 2022 00:00:00 +0000</pubDate><guid>https://validatedpatterns.io/patterns/retail/</guid><description>This pattern demonstrates a pattern that models the store side of a retail application.</description></item><item><title>Ansible Edge GitOps</title><link>https://validatedpatterns.io/patterns/ansible-edge-gitops/</link><pubDate>Wed, 08 Jun 2022 00:00:00 +0000</pubDate><guid>https://validatedpatterns.io/patterns/ansible-edge-gitops/</guid><description>This pattern uses OpenShift Virtualization to simulate an edge environment for VMs.</description></item><item><title>Multicluster DevSecOps</title><link>https://validatedpatterns.io/patterns/devsecops/</link><pubDate>Wed, 08 Jun 2022 00:00:00 +0000</pubDate><guid>https://validatedpatterns.io/patterns/devsecops/</guid><description>This pattern is derived from the multi-cloud GitOps pattern with added products to provide a complete DevSecOps workflow.</description></item><item><title>Multicloud GitOps</title><link>https://validatedpatterns.io/patterns/multicloud-gitops/</link><pubDate>Sat, 11 Dec 2021 00:00:00 +0000</pubDate><guid>https://validatedpatterns.io/patterns/multicloud-gitops/</guid><description>This pattern helps you develop and deploy applications on an open hybrid cloud in a stable, simple, and secure way.</description></item><item><title>Industrial Edge</title><link>https://validatedpatterns.io/patterns/industrial-edge/</link><pubDate>Tue, 12 Oct 2021 00:00:00 +0000</pubDate><guid>https://validatedpatterns.io/patterns/industrial-edge/</guid><description>This pattern demonstrates a horizontal solution for Industrial Edge use cases.</description></item><item><title>Medical Diagnosis</title><link>https://validatedpatterns.io/patterns/medical-diagnosis/</link><pubDate>Tue, 19 Jan 2021 00:00:00 +0000</pubDate><guid>https://validatedpatterns.io/patterns/medical-diagnosis/</guid><description>This pattern is based on a demo implementation of an automated data pipeline for chest X-ray analysis previously developed by Red Hat.</description></item><item><title>Cockroach</title><link>https://validatedpatterns.io/patterns/cockroachdb/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://validatedpatterns.io/patterns/cockroachdb/</guid><description>A multicloud pattern using cockroachdb and submariner, deployed via RHACM.</description></item><item><title>Connected Vehicle Architecture</title><link>https://validatedpatterns.io/patterns/connected-vehicle-architecture/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://validatedpatterns.io/patterns/connected-vehicle-architecture/</guid><description>A distributed cloud-native application that implements key aspects of a modern IoT architecture.</description></item><item><title>Kong</title><link>https://validatedpatterns.io/patterns/kong-gateway/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://validatedpatterns.io/patterns/kong-gateway/</guid><description>A pattern for Kong Gateway Control Plane and Data Plane demo.</description></item><item><title>Multicloud GitOps with Portworx Enterprise</title><link>https://validatedpatterns.io/patterns/multicloud-gitops-portworx/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://validatedpatterns.io/patterns/multicloud-gitops-portworx/</guid><description>This pattern helps you develop and deploy applications on an open hybrid cloud in a stable, simple, and secure way. It includes persistent storage for stateful applications.</description></item></channel></rss>
\ No newline at end of file
diff --git a/rh_products/red-hat-openshift-container-platform/page/2/index.html b/rh_products/red-hat-openshift-container-platform/page/2/index.html
index b7bc7bece..cab45a1c4 100644
--- a/rh_products/red-hat-openshift-container-platform/page/2/index.html
+++ b/rh_products/red-hat-openshift-container-platform/page/2/index.html
@@ -1,3 +1,3 @@
 <!doctype html><html><head><link rel=stylesheet href=https://validatedpatterns.io/sass/patternfly.css><link rel=stylesheet href=/css/custom.css><link rel=stylesheet href=https://validatedpatterns.io/sass/patternfly-addons.css><link rel=stylesheet href=https://use.fontawesome.com/releases/v6.3.0/css/solid.css><link rel=stylesheet href=https://use.fontawesome.com/releases/v6.3.0/css/fontawesome.css><link rel=stylesheet href=https://use.fontawesome.com/releases/v6.3.0/css/brands.css><title>Red Hat OpenShift Container Platform | Validated Patterns</title></head><body><div class=pf-c-page><header class=pf-c-page__header><div class=pf-c-page__header-brand><a href=/ class=pf-c-page__header-brand-link><img src=/images/validated-patterns.png alt="Validated Patterns"></a></div><div class=pf-c-page__header-tools><nav class="pf-c-nav pf-m-horizontal" role=navigation><ul class=pf-c-nav__list><li class=pf-c-nav__item><a class=pf-c-nav__link href=/patterns/ title=Patterns>Patterns</a></li><li class=pf-c-nav__item><a class=pf-c-nav__link href=/learn/ title="Learn about Validated Patterns">Learn</a></li><li class=pf-c-nav__item><a class=pf-c-nav__link href=https://play.validatedpatterns.io title>Workshop</a></li><li class=pf-c-nav__item><a class=pf-c-nav__link href=/contribute/ title="Contribute to Validated Patterns">Contribute</a></li><li class=pf-c-nav__item><a class=pf-c-nav__link href=/blog/ title=Blog>Blog</a></li><li class=pf-c-nav__item><a class=pf-c-nav__link href=/ci/ title="CI Status">Status</a></li></ul></nav><form id=search action=https://validatedpatterns.io/search/ method=get><div class=pf-c-search-input><div class=pf-c-input-group><div class=pf-c-search-input__bar><span class=pf-c-search-input__text><span class=pf-c-search-input__icon><i class="fas fa-search fa-fw" aria-hidden=true></i>
 </span><input id=search-input name=query class=pf-c-search-input__text-input type=text placeholder=Search aria-label=Search></span></div><button form=search class="pf-c-button pf-m-control" type=submit aria-label=Search value=search>
-<i class="fas fa-arrow-right" aria-hidden=true></i></button></div></div></form></div></header><main class=pf-c-page__main><section class=pf-c-page__main-section><div class=pf-l-stack><div class=pf-c-content style=--pf-c-content--FontSize:1.25rem></div></div></section><div><div><div class=pf-c-card style=text-align:left><div class=pf-c-card__title><h1><a href=/patterns/hypershift/>HyperShift</a></h1></div><div class=pf-c-card__body>This pattern is for deploying the Hosted Control Plane (HyperShift) service.</div><div class=pf-c-card__footer><a href=/patterns/hypershift/></a></div></div></div><div><div class=pf-c-card style=text-align:left><div class=pf-c-card__title><h1><a href=/patterns/mlops-fraud-detection/>MLOps Fraud Detection</a></h1></div><div class=pf-c-card__body>This pattern demonstrates how Red Hat OpenShift Data Science and MLFlow can be used together to build an end-to-end MLOps platform. It demonstrates this using a credit card fraud detection use case.</div><div class=pf-c-card__footer><a href=/patterns/mlops-fraud-detection/></a></div></div></div><div><div class=pf-c-card style=text-align:left><div class=pf-c-card__title><h1><a href=/patterns/emerging-disease-detection/>Emerging Disease Detection</a></h1></div><div class=pf-c-card__body>This pattern is based on a demo implementation of an automated data pipeline for sepsis analysis previously developed by Red Hat.</div><div class=pf-c-card__footer><a href=/patterns/emerging-disease-detection/></a></div></div></div><div><div class=pf-c-card style=text-align:left><div class=pf-c-card__title><h1><a href=/patterns/retail/>Retail</a></h1></div><div class=pf-c-card__body>This pattern demonstrates a pattern that models the store side of a retail application.</div><div class=pf-c-card__footer><a href=/patterns/retail/></a></div></div></div><div><div class=pf-c-card style=text-align:left><div class=pf-c-card__title><h1><a href=/patterns/ansible-edge-gitops/>Ansible Edge GitOps</a></h1></div><div class=pf-c-card__body>This pattern uses OpenShift Virtualization to simulate an edge environment for VMs.</div><div class=pf-c-card__footer><a href=/patterns/ansible-edge-gitops/></a></div></div></div><div><div class=pf-c-card style=text-align:left><div class=pf-c-card__title><h1><a href=/patterns/devsecops/>Multicluster DevSecOps</a></h1></div><div class=pf-c-card__body>This pattern is derived from the multi-cloud GitOps pattern with added products to provide a complete DevSecOps workflow.</div><div class=pf-c-card__footer><a href=/patterns/devsecops/></a></div></div></div><ul class="pagination pagination-default"><li class=page-item><a href=/rh_products/red-hat-openshift-container-platform/ aria-label=First class=page-link role=button><span aria-hidden=true>&#171;&#171;</span></a></li><li class=page-item><a href=/rh_products/red-hat-openshift-container-platform/ aria-label=Previous class=page-link role=button><span aria-hidden=true>&#171;</span></a></li><li class=page-item><a href=/rh_products/red-hat-openshift-container-platform/ aria-label="Page 1" class=page-link role=button>1</a></li><li class="page-item active"><a aria-current=page aria-label="Page 2" class=page-link role=button>2</a></li><li class=page-item><a href=/rh_products/red-hat-openshift-container-platform/page/3/ aria-label="Page 3" class=page-link role=button>3</a></li><li class=page-item><a href=/rh_products/red-hat-openshift-container-platform/page/4/ aria-label="Page 4" class=page-link role=button>4</a></li><li class=page-item><a href=/rh_products/red-hat-openshift-container-platform/page/3/ aria-label=Next class=page-link role=button><span aria-hidden=true>&#187;</span></a></li><li class=page-item><a href=/rh_products/red-hat-openshift-container-platform/page/4/ aria-label=Last class=page-link role=button><span aria-hidden=true>&#187;&#187;</span></a></li></ul></div></main></div><script src=/js/codeblock.js></script></body></html>
\ No newline at end of file
+<i class="fas fa-arrow-right" aria-hidden=true></i></button></div></div></form></div></header><main class=pf-c-page__main><section class=pf-c-page__main-section><div class=pf-l-stack><div class=pf-c-content style=--pf-c-content--FontSize:1.25rem></div></div></section><div><div><div class=pf-c-card style=text-align:left><div class=pf-c-card__title><h1><a href=/patterns/travelops/>TravelOps</a></h1></div><div class=pf-c-card__body>This pattern enables you to secure your applications using Red Hat Service Mesh.</div><div class=pf-c-card__footer><a href=/patterns/travelops/></a></div></div></div><div><div class=pf-c-card style=text-align:left><div class=pf-c-card__title><h1><a href=/patterns/hypershift/>HyperShift</a></h1></div><div class=pf-c-card__body>This pattern is for deploying the Hosted Control Plane (HyperShift) service.</div><div class=pf-c-card__footer><a href=/patterns/hypershift/></a></div></div></div><div><div class=pf-c-card style=text-align:left><div class=pf-c-card__title><h1><a href=/patterns/mlops-fraud-detection/>MLOps Fraud Detection</a></h1></div><div class=pf-c-card__body>This pattern demonstrates how Red Hat OpenShift Data Science and MLFlow can be used together to build an end-to-end MLOps platform. It demonstrates this using a credit card fraud detection use case.</div><div class=pf-c-card__footer><a href=/patterns/mlops-fraud-detection/></a></div></div></div><div><div class=pf-c-card style=text-align:left><div class=pf-c-card__title><h1><a href=/patterns/emerging-disease-detection/>Emerging Disease Detection</a></h1></div><div class=pf-c-card__body>This pattern is based on a demo implementation of an automated data pipeline for sepsis analysis previously developed by Red Hat.</div><div class=pf-c-card__footer><a href=/patterns/emerging-disease-detection/></a></div></div></div><div><div class=pf-c-card style=text-align:left><div class=pf-c-card__title><h1><a href=/patterns/retail/>Retail</a></h1></div><div class=pf-c-card__body>This pattern demonstrates a pattern that models the store side of a retail application.</div><div class=pf-c-card__footer><a href=/patterns/retail/></a></div></div></div><div><div class=pf-c-card style=text-align:left><div class=pf-c-card__title><h1><a href=/patterns/ansible-edge-gitops/>Ansible Edge GitOps</a></h1></div><div class=pf-c-card__body>This pattern uses OpenShift Virtualization to simulate an edge environment for VMs.</div><div class=pf-c-card__footer><a href=/patterns/ansible-edge-gitops/></a></div></div></div><ul class="pagination pagination-default"><li class=page-item><a href=/rh_products/red-hat-openshift-container-platform/ aria-label=First class=page-link role=button><span aria-hidden=true>&#171;&#171;</span></a></li><li class=page-item><a href=/rh_products/red-hat-openshift-container-platform/ aria-label=Previous class=page-link role=button><span aria-hidden=true>&#171;</span></a></li><li class=page-item><a href=/rh_products/red-hat-openshift-container-platform/ aria-label="Page 1" class=page-link role=button>1</a></li><li class="page-item active"><a aria-current=page aria-label="Page 2" class=page-link role=button>2</a></li><li class=page-item><a href=/rh_products/red-hat-openshift-container-platform/page/3/ aria-label="Page 3" class=page-link role=button>3</a></li><li class=page-item><a href=/rh_products/red-hat-openshift-container-platform/page/4/ aria-label="Page 4" class=page-link role=button>4</a></li><li class=page-item><a href=/rh_products/red-hat-openshift-container-platform/page/3/ aria-label=Next class=page-link role=button><span aria-hidden=true>&#187;</span></a></li><li class=page-item><a href=/rh_products/red-hat-openshift-container-platform/page/4/ aria-label=Last class=page-link role=button><span aria-hidden=true>&#187;&#187;</span></a></li></ul></div></main></div><script src=/js/codeblock.js></script></body></html>
\ No newline at end of file
diff --git a/rh_products/red-hat-openshift-container-platform/page/3/index.html b/rh_products/red-hat-openshift-container-platform/page/3/index.html
index 27774b443..e3e97011e 100644
--- a/rh_products/red-hat-openshift-container-platform/page/3/index.html
+++ b/rh_products/red-hat-openshift-container-platform/page/3/index.html
@@ -1,3 +1,3 @@
 <!doctype html><html><head><link rel=stylesheet href=https://validatedpatterns.io/sass/patternfly.css><link rel=stylesheet href=/css/custom.css><link rel=stylesheet href=https://validatedpatterns.io/sass/patternfly-addons.css><link rel=stylesheet href=https://use.fontawesome.com/releases/v6.3.0/css/solid.css><link rel=stylesheet href=https://use.fontawesome.com/releases/v6.3.0/css/fontawesome.css><link rel=stylesheet href=https://use.fontawesome.com/releases/v6.3.0/css/brands.css><title>Red Hat OpenShift Container Platform | Validated Patterns</title></head><body><div class=pf-c-page><header class=pf-c-page__header><div class=pf-c-page__header-brand><a href=/ class=pf-c-page__header-brand-link><img src=/images/validated-patterns.png alt="Validated Patterns"></a></div><div class=pf-c-page__header-tools><nav class="pf-c-nav pf-m-horizontal" role=navigation><ul class=pf-c-nav__list><li class=pf-c-nav__item><a class=pf-c-nav__link href=/patterns/ title=Patterns>Patterns</a></li><li class=pf-c-nav__item><a class=pf-c-nav__link href=/learn/ title="Learn about Validated Patterns">Learn</a></li><li class=pf-c-nav__item><a class=pf-c-nav__link href=https://play.validatedpatterns.io title>Workshop</a></li><li class=pf-c-nav__item><a class=pf-c-nav__link href=/contribute/ title="Contribute to Validated Patterns">Contribute</a></li><li class=pf-c-nav__item><a class=pf-c-nav__link href=/blog/ title=Blog>Blog</a></li><li class=pf-c-nav__item><a class=pf-c-nav__link href=/ci/ title="CI Status">Status</a></li></ul></nav><form id=search action=https://validatedpatterns.io/search/ method=get><div class=pf-c-search-input><div class=pf-c-input-group><div class=pf-c-search-input__bar><span class=pf-c-search-input__text><span class=pf-c-search-input__icon><i class="fas fa-search fa-fw" aria-hidden=true></i>
 </span><input id=search-input name=query class=pf-c-search-input__text-input type=text placeholder=Search aria-label=Search></span></div><button form=search class="pf-c-button pf-m-control" type=submit aria-label=Search value=search>
-<i class="fas fa-arrow-right" aria-hidden=true></i></button></div></div></form></div></header><main class=pf-c-page__main><section class=pf-c-page__main-section><div class=pf-l-stack><div class=pf-c-content style=--pf-c-content--FontSize:1.25rem></div></div></section><div><div><div class=pf-c-card style=text-align:left><div class=pf-c-card__title><h1><a href=/patterns/multicloud-gitops/>Multicloud GitOps</a></h1></div><div class=pf-c-card__body>This pattern helps you develop and deploy applications on an open hybrid cloud in a stable, simple, and secure way.</div><div class=pf-c-card__footer><a href=/patterns/multicloud-gitops/></a></div></div></div><div><div class=pf-c-card style=text-align:left><div class=pf-c-card__title><h1><a href=/patterns/industrial-edge/>Industrial Edge</a></h1></div><div class=pf-c-card__body>This pattern demonstrates a horizontal solution for Industrial Edge use cases.</div><div class=pf-c-card__footer><a href=/patterns/industrial-edge/></a></div></div></div><div><div class=pf-c-card style=text-align:left><div class=pf-c-card__title><h1><a href=/patterns/medical-diagnosis/>Medical Diagnosis</a></h1></div><div class=pf-c-card__body>This pattern is based on a demo implementation of an automated data pipeline for chest X-ray analysis previously developed by Red Hat.</div><div class=pf-c-card__footer><a href=/patterns/medical-diagnosis/></a></div></div></div><div><div class=pf-c-card style=text-align:left><div class=pf-c-card__title><h1><a href=/patterns/cockroachdb/>Cockroach</a></h1></div><div class=pf-c-card__body>A multicloud pattern using cockroachdb and submariner, deployed via RHACM.</div><div class=pf-c-card__footer><a href=/patterns/cockroachdb/></a></div></div></div><div><div class=pf-c-card style=text-align:left><div class=pf-c-card__title><h1><a href=/patterns/connected-vehicle-architecture/>Connected Vehicle Architecture</a></h1></div><div class=pf-c-card__body>A distributed cloud-native application that implements key aspects of a modern IoT architecture.</div><div class=pf-c-card__footer><a href=/patterns/connected-vehicle-architecture/></a></div></div></div><div><div class=pf-c-card style=text-align:left><div class=pf-c-card__title><h1><a href=/patterns/kong-gateway/>Kong</a></h1></div><div class=pf-c-card__body>A pattern for Kong Gateway Control Plane and Data Plane demo.</div><div class=pf-c-card__footer><a href=/patterns/kong-gateway/></a></div></div></div><ul class="pagination pagination-default"><li class=page-item><a href=/rh_products/red-hat-openshift-container-platform/ aria-label=First class=page-link role=button><span aria-hidden=true>&#171;&#171;</span></a></li><li class=page-item><a href=/rh_products/red-hat-openshift-container-platform/page/2/ aria-label=Previous class=page-link role=button><span aria-hidden=true>&#171;</span></a></li><li class=page-item><a href=/rh_products/red-hat-openshift-container-platform/ aria-label="Page 1" class=page-link role=button>1</a></li><li class=page-item><a href=/rh_products/red-hat-openshift-container-platform/page/2/ aria-label="Page 2" class=page-link role=button>2</a></li><li class="page-item active"><a aria-current=page aria-label="Page 3" class=page-link role=button>3</a></li><li class=page-item><a href=/rh_products/red-hat-openshift-container-platform/page/4/ aria-label="Page 4" class=page-link role=button>4</a></li><li class=page-item><a href=/rh_products/red-hat-openshift-container-platform/page/4/ aria-label=Next class=page-link role=button><span aria-hidden=true>&#187;</span></a></li><li class=page-item><a href=/rh_products/red-hat-openshift-container-platform/page/4/ aria-label=Last class=page-link role=button><span aria-hidden=true>&#187;&#187;</span></a></li></ul></div></main></div><script src=/js/codeblock.js></script></body></html>
\ No newline at end of file
+<i class="fas fa-arrow-right" aria-hidden=true></i></button></div></div></form></div></header><main class=pf-c-page__main><section class=pf-c-page__main-section><div class=pf-l-stack><div class=pf-c-content style=--pf-c-content--FontSize:1.25rem></div></div></section><div><div><div class=pf-c-card style=text-align:left><div class=pf-c-card__title><h1><a href=/patterns/devsecops/>Multicluster DevSecOps</a></h1></div><div class=pf-c-card__body>This pattern is derived from the multi-cloud GitOps pattern with added products to provide a complete DevSecOps workflow.</div><div class=pf-c-card__footer><a href=/patterns/devsecops/></a></div></div></div><div><div class=pf-c-card style=text-align:left><div class=pf-c-card__title><h1><a href=/patterns/multicloud-gitops/>Multicloud GitOps</a></h1></div><div class=pf-c-card__body>This pattern helps you develop and deploy applications on an open hybrid cloud in a stable, simple, and secure way.</div><div class=pf-c-card__footer><a href=/patterns/multicloud-gitops/></a></div></div></div><div><div class=pf-c-card style=text-align:left><div class=pf-c-card__title><h1><a href=/patterns/industrial-edge/>Industrial Edge</a></h1></div><div class=pf-c-card__body>This pattern demonstrates a horizontal solution for Industrial Edge use cases.</div><div class=pf-c-card__footer><a href=/patterns/industrial-edge/></a></div></div></div><div><div class=pf-c-card style=text-align:left><div class=pf-c-card__title><h1><a href=/patterns/medical-diagnosis/>Medical Diagnosis</a></h1></div><div class=pf-c-card__body>This pattern is based on a demo implementation of an automated data pipeline for chest X-ray analysis previously developed by Red Hat.</div><div class=pf-c-card__footer><a href=/patterns/medical-diagnosis/></a></div></div></div><div><div class=pf-c-card style=text-align:left><div class=pf-c-card__title><h1><a href=/patterns/cockroachdb/>Cockroach</a></h1></div><div class=pf-c-card__body>A multicloud pattern using cockroachdb and submariner, deployed via RHACM.</div><div class=pf-c-card__footer><a href=/patterns/cockroachdb/></a></div></div></div><div><div class=pf-c-card style=text-align:left><div class=pf-c-card__title><h1><a href=/patterns/connected-vehicle-architecture/>Connected Vehicle Architecture</a></h1></div><div class=pf-c-card__body>A distributed cloud-native application that implements key aspects of a modern IoT architecture.</div><div class=pf-c-card__footer><a href=/patterns/connected-vehicle-architecture/></a></div></div></div><ul class="pagination pagination-default"><li class=page-item><a href=/rh_products/red-hat-openshift-container-platform/ aria-label=First class=page-link role=button><span aria-hidden=true>&#171;&#171;</span></a></li><li class=page-item><a href=/rh_products/red-hat-openshift-container-platform/page/2/ aria-label=Previous class=page-link role=button><span aria-hidden=true>&#171;</span></a></li><li class=page-item><a href=/rh_products/red-hat-openshift-container-platform/ aria-label="Page 1" class=page-link role=button>1</a></li><li class=page-item><a href=/rh_products/red-hat-openshift-container-platform/page/2/ aria-label="Page 2" class=page-link role=button>2</a></li><li class="page-item active"><a aria-current=page aria-label="Page 3" class=page-link role=button>3</a></li><li class=page-item><a href=/rh_products/red-hat-openshift-container-platform/page/4/ aria-label="Page 4" class=page-link role=button>4</a></li><li class=page-item><a href=/rh_products/red-hat-openshift-container-platform/page/4/ aria-label=Next class=page-link role=button><span aria-hidden=true>&#187;</span></a></li><li class=page-item><a href=/rh_products/red-hat-openshift-container-platform/page/4/ aria-label=Last class=page-link role=button><span aria-hidden=true>&#187;&#187;</span></a></li></ul></div></main></div><script src=/js/codeblock.js></script></body></html>
\ No newline at end of file
diff --git a/rh_products/red-hat-openshift-container-platform/page/4/index.html b/rh_products/red-hat-openshift-container-platform/page/4/index.html
index 4323998a0..4190d70bb 100644
--- a/rh_products/red-hat-openshift-container-platform/page/4/index.html
+++ b/rh_products/red-hat-openshift-container-platform/page/4/index.html
@@ -1,3 +1,3 @@
 <!doctype html><html><head><link rel=stylesheet href=https://validatedpatterns.io/sass/patternfly.css><link rel=stylesheet href=/css/custom.css><link rel=stylesheet href=https://validatedpatterns.io/sass/patternfly-addons.css><link rel=stylesheet href=https://use.fontawesome.com/releases/v6.3.0/css/solid.css><link rel=stylesheet href=https://use.fontawesome.com/releases/v6.3.0/css/fontawesome.css><link rel=stylesheet href=https://use.fontawesome.com/releases/v6.3.0/css/brands.css><title>Red Hat OpenShift Container Platform | Validated Patterns</title></head><body><div class=pf-c-page><header class=pf-c-page__header><div class=pf-c-page__header-brand><a href=/ class=pf-c-page__header-brand-link><img src=/images/validated-patterns.png alt="Validated Patterns"></a></div><div class=pf-c-page__header-tools><nav class="pf-c-nav pf-m-horizontal" role=navigation><ul class=pf-c-nav__list><li class=pf-c-nav__item><a class=pf-c-nav__link href=/patterns/ title=Patterns>Patterns</a></li><li class=pf-c-nav__item><a class=pf-c-nav__link href=/learn/ title="Learn about Validated Patterns">Learn</a></li><li class=pf-c-nav__item><a class=pf-c-nav__link href=https://play.validatedpatterns.io title>Workshop</a></li><li class=pf-c-nav__item><a class=pf-c-nav__link href=/contribute/ title="Contribute to Validated Patterns">Contribute</a></li><li class=pf-c-nav__item><a class=pf-c-nav__link href=/blog/ title=Blog>Blog</a></li><li class=pf-c-nav__item><a class=pf-c-nav__link href=/ci/ title="CI Status">Status</a></li></ul></nav><form id=search action=https://validatedpatterns.io/search/ method=get><div class=pf-c-search-input><div class=pf-c-input-group><div class=pf-c-search-input__bar><span class=pf-c-search-input__text><span class=pf-c-search-input__icon><i class="fas fa-search fa-fw" aria-hidden=true></i>
 </span><input id=search-input name=query class=pf-c-search-input__text-input type=text placeholder=Search aria-label=Search></span></div><button form=search class="pf-c-button pf-m-control" type=submit aria-label=Search value=search>
-<i class="fas fa-arrow-right" aria-hidden=true></i></button></div></div></form></div></header><main class=pf-c-page__main><section class=pf-c-page__main-section><div class=pf-l-stack><div class=pf-c-content style=--pf-c-content--FontSize:1.25rem></div></div></section><div><div><div class=pf-c-card style=text-align:left><div class=pf-c-card__title><h1><a href=/patterns/multicloud-gitops-portworx/>Multicloud GitOps with Portworx Enterprise</a></h1></div><div class=pf-c-card__body>This pattern helps you develop and deploy applications on an open hybrid cloud in a stable, simple, and secure way. It includes persistent storage for stateful applications.</div><div class=pf-c-card__footer><a href=/patterns/multicloud-gitops-portworx/></a></div></div></div><ul class="pagination pagination-default"><li class=page-item><a href=/rh_products/red-hat-openshift-container-platform/ aria-label=First class=page-link role=button><span aria-hidden=true>&#171;&#171;</span></a></li><li class=page-item><a href=/rh_products/red-hat-openshift-container-platform/page/3/ aria-label=Previous class=page-link role=button><span aria-hidden=true>&#171;</span></a></li><li class=page-item><a href=/rh_products/red-hat-openshift-container-platform/ aria-label="Page 1" class=page-link role=button>1</a></li><li class=page-item><a href=/rh_products/red-hat-openshift-container-platform/page/2/ aria-label="Page 2" class=page-link role=button>2</a></li><li class=page-item><a href=/rh_products/red-hat-openshift-container-platform/page/3/ aria-label="Page 3" class=page-link role=button>3</a></li><li class="page-item active"><a aria-current=page aria-label="Page 4" class=page-link role=button>4</a></li><li class="page-item disabled"><a aria-disabled=true aria-label=Next class=page-link role=button tabindex=-1><span aria-hidden=true>&#187;</span></a></li><li class="page-item disabled"><a aria-disabled=true aria-label=Last class=page-link role=button tabindex=-1><span aria-hidden=true>&#187;&#187;</span></a></li></ul></div></main></div><script src=/js/codeblock.js></script></body></html>
\ No newline at end of file
+<i class="fas fa-arrow-right" aria-hidden=true></i></button></div></div></form></div></header><main class=pf-c-page__main><section class=pf-c-page__main-section><div class=pf-l-stack><div class=pf-c-content style=--pf-c-content--FontSize:1.25rem></div></div></section><div><div><div class=pf-c-card style=text-align:left><div class=pf-c-card__title><h1><a href=/patterns/kong-gateway/>Kong</a></h1></div><div class=pf-c-card__body>A pattern for Kong Gateway Control Plane and Data Plane demo.</div><div class=pf-c-card__footer><a href=/patterns/kong-gateway/></a></div></div></div><div><div class=pf-c-card style=text-align:left><div class=pf-c-card__title><h1><a href=/patterns/multicloud-gitops-portworx/>Multicloud GitOps with Portworx Enterprise</a></h1></div><div class=pf-c-card__body>This pattern helps you develop and deploy applications on an open hybrid cloud in a stable, simple, and secure way. It includes persistent storage for stateful applications.</div><div class=pf-c-card__footer><a href=/patterns/multicloud-gitops-portworx/></a></div></div></div><ul class="pagination pagination-default"><li class=page-item><a href=/rh_products/red-hat-openshift-container-platform/ aria-label=First class=page-link role=button><span aria-hidden=true>&#171;&#171;</span></a></li><li class=page-item><a href=/rh_products/red-hat-openshift-container-platform/page/3/ aria-label=Previous class=page-link role=button><span aria-hidden=true>&#171;</span></a></li><li class=page-item><a href=/rh_products/red-hat-openshift-container-platform/ aria-label="Page 1" class=page-link role=button>1</a></li><li class=page-item><a href=/rh_products/red-hat-openshift-container-platform/page/2/ aria-label="Page 2" class=page-link role=button>2</a></li><li class=page-item><a href=/rh_products/red-hat-openshift-container-platform/page/3/ aria-label="Page 3" class=page-link role=button>3</a></li><li class="page-item active"><a aria-current=page aria-label="Page 4" class=page-link role=button>4</a></li><li class="page-item disabled"><a aria-disabled=true aria-label=Next class=page-link role=button tabindex=-1><span aria-hidden=true>&#187;</span></a></li><li class="page-item disabled"><a aria-disabled=true aria-label=Last class=page-link role=button tabindex=-1><span aria-hidden=true>&#187;&#187;</span></a></li></ul></div></main></div><script src=/js/codeblock.js></script></body></html>
\ No newline at end of file
diff --git a/search/index.html b/search/index.html
index 2072ca369..17821253e 100644
--- a/search/index.html
+++ b/search/index.html
@@ -3736,7 +3736,25 @@
 clusterGroup: applications: test: project: hub chart: nginx chartVersion: 13.2.12 repoURL: https://charts.bitnami.com/bitnami How to develop a chart directly from git It is possible to point the framework directly to a git repository pointing to a helm chart. This is especially useful for developing a chart. There are two cases to distinguish here.
 The clustergroup chart. Tweak values-global.yaml as follows:
 spec: clusterGroupName: hub multiSourceConfig: enabled: true clusterGroupGitRepoUrl: https://github.com/myorg/clustergroup-chart clusterGroupChartGitRevision: dev-branch For all the other charts we just need to add repoURL, path and the chartVersion fields:
-clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
+clusterGroup: applications: acm: name: acm namespace: open-cluster-management project: hub path: &#34;.&#34; chartVersion: dev-branch repoURL: https://github.com/myorg/acm-chart `,url:"https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/",breadcrumb:"/blog/2024-09-26-slimming-of-common/"},"https://validatedpatterns.io/patterns/regional-dr/":{title:"Regional Disaster Recovery",tags:[],content:`OpenShift Regional DR Context As more and more institution and mission critical organizations are moving in the cloud, the possible impact of having a provider failure, might this be only related to only one region, is very high.
+This pattern is designed to prove the resiliency capabilities of Red Hat Openshift in such scenario.
+The Regional Disaster Recovery Pattern, is designed to setup an multiple instances of Openshift Container Platform cluster connectedbetween them to prove multi-region resiliency by maintaing the application running in the event of a regional failure.
+In this scenario we will be working in a Regional Disaster Recovery setup, and the synchronization parameters can be specified in the value file.
+NOTE: please consider using longer times if you have a large dataset or very long distances between the clusters
+Background The Regional DR Validated Pattern for Red Hat OpenShift increases the resiliency of your applications by connecting multiple clusters across different regions. This pattern uses Red Hat Advanced Cluster Management to offer a Red Hat OpenShift Data Foundation-based multi-region disaster recovery plan if an entire region fails.
+Red Hat OpenShift Data Foundation offers two solutions for disaster recovery: Metro DR and Regional DR. As their name suggests, Metro DR refers to a metropolitan area disasters, which occur when the disaster covers only a single area in a region (availability zone), and Regional DR refers to when the entire region fails. Currently, only active-passive mode is supported.
+A word on synchronization. A metropolitan network generally offers less latency; data can be written to multiple targets simultaneously, a feature required for active-active DR designs. On the other hand, writing to multiple targets in a cross-regional network might introduce unbearable latency to data synchronization and our applications. Therefore, Regional DR can only work with active-passive DR designs, where the targets are replicated asynchronously.
+The synchronization between Availability Zones is faster and can be performed synchronous. However, in order don&rsquo;t include a lot of latency on the data synchronization process, when data is replicated across regions, it necessary includes latencies based on the distance between both regions (e.g. The latency between two regions on Europe, will always be less than between Europe and Asia, so consider this when designing your infrastructure deployment on the values files of the pattern). This is the main reason because this RegionalDR is configured in an Active-Passive mode.
+It requires an already existing Openshift cluster, which will be used for installing the pattern, deploying active and passive clusters manage the application scheduling.
+Prerequisites Installing this pattern requires:
+One online Red Hat OpenShift cluster to become the &ldquo;Manager&rdquo; cluster. This cluster will orchestrate application deployments and data synchronizations. Connection to a Cloud Provider (AWS/Azure/GCP) configured in the Manager cluster. This is required for deploying the active and passive OCP clusters. Red Hat OpenShift CLI installed Solution elements The Regional DR Pattern leverages Red Hat OpenShift Data Foundation&rsquo;s Regional DR solution, automating applications failover between Red Had Advanced Cluster Management managed clusters in different regions.
+The pattern is kick-started by ansible and uses ACM to overlook and orchestrate the process The demo application uses MongoDB writing its data on a Persistent Volume Claim backe by ODF We have developed a DR trigger which will be used to start the DR process The end user needs to configure which PV&rsquo;s need synchronization and the latencies ACS Can be used for eventual policies The clusters are connected by submariner and, to have a faster recovery time, we suggest having hybernated clusters ready to be used Red Hat Technologies Red Hat Openshift Container Platform Red Hat Openshift Data Foundation Red Hat Openshift GitOps Red Hat Openshift Advanced Cluster Management Red Hat Openshift Advanced Cluster Security Operators and Technologies this Pattern Uses Regional DR Trigger Operator Submariner Tested on Red Hat Openshift Container Platform v4.13 Red Hat Openshift Container Platform v4.14 Red Hat Openshift Container Platform v4.15 Architecture This section explains the architecture deployed by this Pattern and its Logical and Physical perspectives. Logical architecture Installation This patterns is designed to be installed in an Openshift cluster which will work as the orchestrator for the other clusters involved. The Adanced Cluster Manager installed will neither run the applications nor store any data from them, but it will take care of the plumbing of the various clusters involved, coordinating their communication and orchestrating when and where an application is going to be deployed.
+As part of the pattern configuration, the administrator needs to define both clusters installation details as would be done using the Openshift-installer binary.
+For installing the pattern, follow the next steps:
+Fork the Pattern. Describe the instructions for creating the clusters and syncing data between them. Commit and push your changes (to your fork). Set your secret cloud provider credentials. Connect to your target Hub cluster. Install the Pattern. Start deploying resilient applications. Pattern Configuration For a full example, check the Pattern&rsquo;s values.yaml. The install-config specifications are detailed here.
+Detailed configuration instructions can be found here.
+Owners For any request, bug report or comment about this pattern, please forward it to:
+Alejandro Villegas (avillega@rehat.com) Tomer Figenblat (tfigenbl@redhat.com) `,url:"https://validatedpatterns.io/patterns/regional-dr/",breadcrumb:"/patterns/regional-dr/"},"https://validatedpatterns.io/blog/2024-09-13-using-hypershift/":{title:"Using HyperShift",tags:[],content:`Getting Started Hosted Control Planes (aka: HyperShift) is project that enables rapid provisioning and deprovisioning of OpenShift clusters. Use this guide to create and delete your hostedclusters and to interrogate the hostingcluster for compute resource information. Upstream documentation can be found HyperShift Upstream Project Docs
 PreReqs and Assumptions Deploying HyperShift clusters requires the following:
 Resource Default Path Description hcp
 /usr/local/bin
diff --git a/sitemap.xml b/sitemap.xml
index c96d5f34a..155c8462c 100644
--- a/sitemap.xml
+++ b/sitemap.xml
@@ -1 +1 @@
-<?xml version="1.0" encoding="utf-8" standalone="yes"?><urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9" xmlns:xhtml="http://www.w3.org/1999/xhtml"><url><loc>https://validatedpatterns.io/learn/about-validated-patterns/</loc></url><url><loc>https://validatedpatterns.io/patterns/coco-pattern/coco-pattern-azure-requirements/</loc></url><url><loc>https://validatedpatterns.io/contribute/contribute-to-docs/</loc></url><url><loc>https://validatedpatterns.io/patterns/coco-pattern/coco-pattern-getting-started/</loc></url><url><loc>https://validatedpatterns.io/patterns/emerging-disease-detection/edd-getting-started/</loc></url><url><loc>https://validatedpatterns.io/patterns/gaudi-rag-chat-qna/gaudi-rag-chat-qna-getting-started/</loc></url><url><loc>https://validatedpatterns.io/patterns/mlops-fraud-detection/mfd-getting-started/</loc></url><url><loc>https://validatedpatterns.io/patterns/multicloud-gitops-amx-rhoai/mcg-amx-rhoai-getting-started/</loc></url><url><loc>https://validatedpatterns.io/patterns/multicloud-gitops-amx/mcg-amx-getting-started/</loc></url><url><loc>https://validatedpatterns.io/patterns/multicloud-gitops-qat/mcg-qat-getting-started/</loc></url><url><loc>https://validatedpatterns.io/patterns/multicloud-gitops-sgx-hello-world/mcg-sgx-hello-world-getting-started/</loc></url><url><loc>https://validatedpatterns.io/patterns/multicloud-gitops-sgx/mcg-sgx-getting-started/</loc></url><url><loc>https://validatedpatterns.io/patterns/multicloud-gitops/mcg-getting-started/</loc></url><url><loc>https://validatedpatterns.io/patterns/ansible-edge-gitops-kasten/getting-started/</loc></url><url><loc>https://validatedpatterns.io/patterns/ansible-edge-gitops/getting-started/</loc></url><url><loc>https://validatedpatterns.io/patterns/devsecops/getting-started/</loc></url><url><loc>https://validatedpatterns.io/patterns/industrial-edge/getting-started/</loc></url><url><loc>https://validatedpatterns.io/patterns/medical-diagnosis-amx/getting-started/</loc></url><url><loc>https://validatedpatterns.io/patterns/medical-diagnosis/getting-started/</loc></url><url><loc>https://validatedpatterns.io/patterns/multicloud-gitops-portworx/getting-started/</loc></url><url><loc>https://validatedpatterns.io/patterns/openshift-ai/getting-started/</loc></url><url><loc>https://validatedpatterns.io/patterns/rag-llm-gitops/getting-started/</loc></url><url><loc>https://validatedpatterns.io/patterns/retail/getting-started/</loc></url><url><loc>https://validatedpatterns.io/patterns/travelops/getting-started/</loc></url><url><loc>https://validatedpatterns.io/patterns/mlops-fraud-detection/mfd-running-the-demo/</loc></url><url><loc>https://validatedpatterns.io/learn/about-pattern-tiers-types/</loc></url><url><loc>https://validatedpatterns.io/contribute/background-on-pattern-development/</loc></url><url><loc>https://validatedpatterns.io/patterns/medical-diagnosis-amx/cluster-sizing/</loc></url><url><loc>https://validatedpatterns.io/patterns/medical-diagnosis/cluster-sizing/</loc></url><url><loc>https://validatedpatterns.io/patterns/industrial-edge/factory/</loc></url><url><loc>https://validatedpatterns.io/patterns/rag-llm-gitops/gpu_provisioning/</loc></url><url><loc>https://validatedpatterns.io/patterns/multicloud-gitops-amx-rhoai/mcg-amx-rhoai-demo-script/</loc></url><url><loc>https://validatedpatterns.io/patterns/ansible-edge-gitops-kasten/installation-details/</loc></url><url><loc>https://validatedpatterns.io/patterns/ansible-edge-gitops/installation-details/</loc></url><url><loc>https://validatedpatterns.io/patterns/multicloud-gitops-amx/mcg-amx-managed-cluster/</loc></url><url><loc>https://validatedpatterns.io/patterns/multicloud-gitops-portworx/managed-cluster/</loc></url><url><loc>https://validatedpatterns.io/patterns/multicloud-gitops-qat/mcg-qat-managed-cluster/</loc></url><url><loc>https://validatedpatterns.io/patterns/multicloud-gitops-sgx-hello-world/mcg-sgx-hello-world-managed-cluster/</loc></url><url><loc>https://validatedpatterns.io/patterns/multicloud-gitops-sgx/mcg-sgx-managed-cluster/</loc></url><url><loc>https://validatedpatterns.io/patterns/multicloud-gitops/mcg-managed-cluster/</loc></url><url><loc>https://validatedpatterns.io/patterns/devsecops/devel-cluster/</loc></url><url><loc>https://validatedpatterns.io/patterns/retail/store/</loc></url><url><loc>https://validatedpatterns.io/learn/validated_patterns_frameworks/</loc></url><url><loc>https://validatedpatterns.io/learn/vp_openshift_framework/</loc></url><url><loc>https://validatedpatterns.io/learn/vp_structure_vp_pattern/</loc></url><url><loc>https://validatedpatterns.io/learn/vp_agof/</loc></url><url><loc>https://validatedpatterns.io/learn/vp_agof_config_controller/</loc></url><url><loc>https://validatedpatterns.io/patterns/industrial-edge/application/</loc></url><url><loc>https://validatedpatterns.io/patterns/retail/application/</loc></url><url><loc>https://validatedpatterns.io/patterns/multicloud-gitops-amx/mcg-amx-cluster-sizing/</loc></url><url><loc>https://validatedpatterns.io/patterns/multicloud-gitops-qat/mcg-qat-cluster-sizing/</loc></url><url><loc>https://validatedpatterns.io/patterns/multicloud-gitops-sgx-hello-world/mcg-sgx-hello-world-cluster-sizing/</loc></url><url><loc>https://validatedpatterns.io/patterns/multicloud-gitops-sgx/mcg-sgx-cluster-sizing/</loc></url><url><loc>https://validatedpatterns.io/patterns/multicloud-gitops/mcg-cluster-sizing/</loc></url><url><loc>https://validatedpatterns.io/patterns/ansible-edge-gitops-kasten/cluster-sizing/</loc></url><url><loc>https://validatedpatterns.io/patterns/ansible-edge-gitops/cluster-sizing/</loc></url><url><loc>https://validatedpatterns.io/patterns/multicloud-gitops-portworx/cluster-sizing/</loc></url><url><loc>https://validatedpatterns.io/patterns/retail/components/</loc></url><url><loc>https://validatedpatterns.io/patterns/multicloud-gitops-sgx-hello-world/mcg-sgx-hello-world-demo-script/</loc></url><url><loc>https://validatedpatterns.io/contribute/extending-a-pattern/</loc></url><url><loc>https://validatedpatterns.io/patterns/multicloud-gitops-amx-rhoai/mcg-amx-rhoai-bert-script/</loc></url><url><loc>https://validatedpatterns.io/learn/keyconcepts/</loc></url><url><loc>https://validatedpatterns.io/patterns/gaudi-rag-chat-qna/gaudi-rag-chat-qna-required-hardware/</loc></url><url><loc>https://validatedpatterns.io/patterns/devsecops/production-cluster/</loc></url><url><loc>https://validatedpatterns.io/patterns/ansible-edge-gitops-kasten/ansible-automation-platform/</loc></url><url><loc>https://validatedpatterns.io/patterns/ansible-edge-gitops/ansible-automation-platform/</loc></url><url><loc>https://validatedpatterns.io/contribute/creating-a-pattern/</loc></url><url><loc>https://validatedpatterns.io/patterns/multicloud-gitops-amx/mcg-amx-imperative-actions/</loc></url><url><loc>https://validatedpatterns.io/patterns/multicloud-gitops-qat/mcg-qat-imperative-actions/</loc></url><url><loc>https://validatedpatterns.io/patterns/multicloud-gitops-sgx-hello-world/mcg-sgx-hello-world-imperative-actions/</loc></url><url><loc>https://validatedpatterns.io/patterns/multicloud-gitops-sgx/mcg-sgx-imperative-actions/</loc></url><url><loc>https://validatedpatterns.io/patterns/multicloud-gitops/mcg-imperative-actions/</loc></url><url><loc>https://validatedpatterns.io/patterns/devsecops/secure-supply-chain-demo/</loc></url><url><loc>https://validatedpatterns.io/learn/quickstart/</loc></url><url><loc>https://validatedpatterns.io/patterns/gaudi-rag-chat-qna/gaudi-rag-chat-qna-troubleshooting/</loc></url><url><loc>https://validatedpatterns.io/patterns/industrial-edge/troubleshooting/</loc></url><url><loc>https://validatedpatterns.io/patterns/medical-diagnosis-amx/troubleshooting/</loc></url><url><loc>https://validatedpatterns.io/patterns/medical-diagnosis/troubleshooting/</loc></url><url><loc>https://validatedpatterns.io/patterns/retail/troubleshooting/</loc></url><url><loc>https://validatedpatterns.io/learn/importing-a-cluster/</loc></url><url><loc>https://validatedpatterns.io/learn/ocp-cluster-general-sizing/</loc></url><url><loc>https://validatedpatterns.io/patterns/devsecops/cluster-sizing/</loc></url><url><loc>https://validatedpatterns.io/patterns/industrial-edge/cluster-sizing/</loc></url><url><loc>https://validatedpatterns.io/patterns/retail/cluster-sizing/</loc></url><url><loc>https://validatedpatterns.io/patterns/medical-diagnosis-amx/ideas-for-customization/</loc></url><url><loc>https://validatedpatterns.io/patterns/medical-diagnosis/ideas-for-customization/</loc></url><url><loc>https://validatedpatterns.io/patterns/travelops/ideas-for-customization/</loc></url><url><loc>https://validatedpatterns.io/learn/infrastructure/</loc></url><url><loc>https://validatedpatterns.io/patterns/multicloud-gitops-amx-rhoai/mcg-amx-rhoai-managed-cluster/</loc></url><url><loc>https://validatedpatterns.io/patterns/ansible-edge-gitops-kasten/openshift-virtualization/</loc></url><url><loc>https://validatedpatterns.io/patterns/ansible-edge-gitops/openshift-virtualization/</loc></url><url><loc>https://validatedpatterns.io/learn/test-artifacts/</loc></url><url><loc>https://validatedpatterns.io/learn/using-validated-pattern-operator/</loc></url><url><loc>https://validatedpatterns.io/learn/clustergroup-in-values-files/</loc></url><url><loc>https://validatedpatterns.io/patterns/ansible-edge-gitops-kasten/veeam-kasten/</loc></url><url><loc>https://validatedpatterns.io/patterns/multicloud-gitops-amx-rhoai/mcg-amx-rhoai-cluster-sizing/</loc></url><url><loc>https://validatedpatterns.io/patterns/medical-diagnosis/demo-script/</loc></url><url><loc>https://validatedpatterns.io/patterns/multicloud-gitops-sgx/mcg-sgx-demo-script/</loc></url><url><loc>https://validatedpatterns.io/patterns/multicloud-gitops/mcg-demo-script/</loc></url><url><loc>https://validatedpatterns.io/patterns/travelops/demo-script/</loc></url><url><loc>https://validatedpatterns.io/patterns/multicloud-gitops-amx/mcg-amx-ideas-for-customization/</loc></url><url><loc>https://validatedpatterns.io/patterns/multicloud-gitops-qat/mcg-qat-ideas-for-customization/</loc></url><url><loc>https://validatedpatterns.io/patterns/multicloud-gitops-sgx-hello-world/mcg-sgx-hello-world-ideas-for-customization/</loc></url><url><loc>https://validatedpatterns.io/patterns/multicloud-gitops-sgx/mcg-sgx-ideas-for-customization/</loc></url><url><loc>https://validatedpatterns.io/patterns/multicloud-gitops/mcg-ideas-for-customization/</loc></url><url><loc>https://validatedpatterns.io/patterns/ansible-edge-gitops-kasten/ideas-for-customization/</loc></url><url><loc>https://validatedpatterns.io/patterns/ansible-edge-gitops/ideas-for-customization/</loc></url><url><loc>https://validatedpatterns.io/patterns/devsecops/ideas-for-customization/</loc></url><url><loc>https://validatedpatterns.io/patterns/industrial-edge/ideas-for-customization/</loc></url><url><loc>https://validatedpatterns.io/patterns/multicloud-gitops-portworx/ideas-for-customization/</loc></url><url><loc>https://validatedpatterns.io/patterns/retail/ideas-for-customization/</loc></url><url><loc>https://validatedpatterns.io/learn/workflow/</loc></url><url><loc>https://validatedpatterns.io/learn/secrets-management-in-the-validated-patterns-framework/</loc></url><url><loc>https://validatedpatterns.io/learn/vault/</loc></url><url><loc>https://validatedpatterns.io/learn/implementation/</loc></url><url><loc>https://validatedpatterns.io/learn/sandbox/</loc></url><url><loc>https://validatedpatterns.io/learn/tested/</loc></url><url><loc>https://validatedpatterns.io/learn/maintained/</loc></url><url><loc>https://validatedpatterns.io/patterns/multicloud-gitops-amx-rhoai/mcg-amx-rhoai-imperative-actions/</loc></url><url><loc>https://validatedpatterns.io/patterns/ansible-edge-gitops-kasten/troubleshooting/</loc></url><url><loc>https://validatedpatterns.io/patterns/ansible-edge-gitops/troubleshooting/</loc></url><url><loc>https://validatedpatterns.io/learn/values-files/</loc></url><url><loc>https://validatedpatterns.io/patterns/multicloud-gitops-amx-rhoai/mcg-amx-rhoai-ideas-for-customization/</loc></url><url><loc>https://validatedpatterns.io/learn/secrets/</loc></url><url><loc>https://validatedpatterns.io/learn/faq/</loc></url><url><loc>https://validatedpatterns.io/blog/2024-11-07-clustergroup-sequencing/</loc><lastmod>2024-11-07T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/blog/</loc><lastmod>2024-11-07T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/blog_tags/</loc><lastmod>2024-11-07T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/blog_tags/how-to/</loc><lastmod>2024-11-07T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/blog_tags/patterns/</loc><lastmod>2024-11-07T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/blog_tags/sequencing/</loc><lastmod>2024-11-07T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/blog_tags/subscriptions/</loc><lastmod>2024-11-07T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/</loc><lastmod>2024-11-07T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/patterns/ansible-edge-gitops-kasten/</loc><lastmod>2024-10-28T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/industries/chemical/</loc><lastmod>2024-10-28T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/industries/</loc><lastmod>2024-10-28T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/other_products/</loc><lastmod>2024-10-28T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/patterns/</loc><lastmod>2024-10-28T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/rh_products/red-hat-ansible-automation-platform/</loc><lastmod>2024-10-28T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/rh_products/red-hat-enterprise-linux/</loc><lastmod>2024-10-28T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/rh_products/red-hat-openshift-container-platform/</loc><lastmod>2024-10-28T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/rh_products/red-hat-openshift-data-foundation/</loc><lastmod>2024-10-28T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/rh_products/red-hat-openshift-virtualization/</loc><lastmod>2024-10-28T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/rh_products/</loc><lastmod>2024-10-28T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/other_products/veeam-kasten/</loc><lastmod>2024-10-28T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/blog/2024-10-12-disconnected/</loc><lastmod>2024-10-12T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/patterns/coco-pattern/</loc><lastmod>2024-10-03T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/industries/general/</loc><lastmod>2024-10-03T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/rh_products/red-hat-advanced-cluster-management/</loc><lastmod>2024-10-03T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/rh_products/red-hat-openshift-sandbox-containers/</loc><lastmod>2024-10-03T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/</loc><lastmod>2024-09-26T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/blog/2024-09-13-using-hypershift/</loc><lastmod>2024-09-13T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/blog/2024-08-30-push-secrets/</loc><lastmod>2024-08-30T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/patterns/rag-llm-gitops/</loc><lastmod>2024-07-25T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/rh_products/red-hat-openshift-gitops/</loc><lastmod>2024-07-25T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/blog/2024-07-19-write-token-kubeconfig/</loc><lastmod>2024-07-19T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/blog_tags/git/</loc><lastmod>2024-07-12T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/blog/2024-07-12-in-cluster-git/</loc><lastmod>2024-07-12T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/patterns/ansible-gitops-framework/</loc><lastmod>2024-06-13T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/patterns/gaudi-rag-chat-qna/</loc><lastmod>2024-06-01T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/rh_products/red-hat-openshift-ai/</loc><lastmod>2024-06-01T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/rh_products/red-hat-openshift-serverless/</loc><lastmod>2024-06-01T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/rh_products/red-hat-openshift-service-mesh/</loc><lastmod>2024-06-01T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/patterns/openshift-ai/</loc><lastmod>2024-04-22T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/rh_products/red-hat-pipelines/</loc><lastmod>2024-04-22T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/patterns/multicloud-gitops-amx-rhoai/</loc><lastmod>2024-02-27T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/patterns/multicloud-gitops-sgx-hello-world/</loc><lastmod>2024-02-20T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/patterns/multicloud-gitops-sgx/</loc><lastmod>2024-02-09T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/rh_products/red-hat-elasticsearch/</loc><lastmod>2024-02-09T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/rh_products/red-hat-jaeger-distributed-tracing/</loc><lastmod>2024-02-09T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/rh_products/red-hat-kiali/</loc><lastmod>2024-02-09T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/rh_products/red-hat-service-mesh/</loc><lastmod>2024-02-09T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/patterns/travelops/</loc><lastmod>2024-02-09T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/blog/2024-02-07-hcp-htpasswd-config/</loc><lastmod>2024-02-07T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/blog_tags/announce/</loc><lastmod>2024-02-02T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/blog/2024-03-05-intel-accelerated-patterns/</loc><lastmod>2024-02-02T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/blog/2024-01-26-more-secrets-options/</loc><lastmod>2024-01-26T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/blog_tags/secrets/</loc><lastmod>2024-01-26T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/blog/2024-01-16-deploying-mcg-with-cisco-flashstack-portworx/</loc><lastmod>2024-01-16T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/blog/2023-12-20-private-repos/</loc><lastmod>2023-12-20T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/blog/2023-12-15-understanding-namespaces/</loc><lastmod>2023-12-15T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/blog_tags/nutanix/</loc><lastmod>2023-12-04T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/blog/2023-12-05-nutanix-testing/</loc><lastmod>2023-12-04T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/blog/2023-12-01-new-pattern-tiers/</loc><lastmod>2023-12-01T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/blog/2023-11-17-argo-configmanagement-plugins/</loc><lastmod>2023-11-17T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/blog_tags/devops/</loc><lastmod>2023-11-17T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/blog_tags/devsecops/</loc><lastmod>2023-11-17T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/blog_tags/gitops/</loc><lastmod>2023-11-17T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/blog_tags/openshift-platform-plus/</loc><lastmod>2023-11-17T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/blog_tags/pipelines/</loc><lastmod>2023-11-17T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/other_products/aws-controller-for-kubernetes/</loc><lastmod>2023-11-15T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/patterns/hypershift/</loc><lastmod>2023-11-15T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/industries/infrastructure/</loc><lastmod>2023-11-15T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/rh_products/red-hat-multicluster-engine/</loc><lastmod>2023-11-15T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/industries/financial-services/</loc><lastmod>2023-11-12T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/patterns/mlops-fraud-detection/</loc><lastmod>2023-11-12T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/rh_products/red-hat-openshift-data-science/</loc><lastmod>2023-11-12T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/patterns/medical-diagnosis-amx/</loc><lastmod>2023-10-10T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/industries/medical/</loc><lastmod>2023-10-10T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/patterns/multicloud-gitops-amx/</loc><lastmod>2023-10-05T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/patterns/multicloud-gitops-qat/</loc><lastmod>2023-10-05T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/patterns/emerging-disease-detection/</loc><lastmod>2023-09-23T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/rh_products/red-hat-amq-streams/</loc><lastmod>2023-09-23T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/rh_products/red-hat-single-sign-on/</loc><lastmod>2023-09-23T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/rh_products/red-hat-amq/</loc><lastmod>2022-12-08T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/industries/retail/</loc><lastmod>2022-12-08T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/patterns/retail/</loc><lastmod>2022-12-08T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/blog_tags/acs/</loc><lastmod>2022-12-01T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/blog/2022-12-01-multicluster-devsecops/</loc><lastmod>2022-12-01T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/blog_tags/quay/</loc><lastmod>2022-12-01T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/blog_tags/security/</loc><lastmod>2022-12-01T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/blog/2022-11-20-argo-rollouts/</loc><lastmod>2022-11-03T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/blog_tags/acm/</loc><lastmod>2022-10-12T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/blog/2022-10-12-acm-provisioning/</loc><lastmod>2022-10-12T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/blog_tags/provisioning/</loc><lastmod>2022-10-12T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/blog_tags/openshift/</loc><lastmod>2022-09-02T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/blog_tags/route/</loc><lastmod>2022-09-02T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/blog/2022-09-02-route/</loc><lastmod>2022-09-02T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/blog_tags/validated-pattern/</loc><lastmod>2022-09-02T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/blog/2022-08-24-clustergroups/</loc><lastmod>2022-08-24T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/blog_tags/ansible-edge-gitops/</loc><lastmod>2022-07-15T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/blog/2022-07-15-push-vs-pull/</loc><lastmod>2022-07-15T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/blog/2022-06-30-ansible-edge-gitops/</loc><lastmod>2022-06-30T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/patterns/ansible-edge-gitops/</loc><lastmod>2022-06-08T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/patterns/devsecops/</loc><lastmod>2022-06-08T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/rh_products/red-hat-advanced-cluster-security/</loc><lastmod>2022-06-08T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/rh_products/red-hat-quay/</loc><lastmod>2022-06-08T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/blog_tags/multi-cloud-gitops/</loc><lastmod>2022-03-30T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/blog/2022-03-30-multicloud-gitops/</loc><lastmod>2022-03-30T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/blog_tags/xray/</loc><lastmod>2022-03-30T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/blog/2022-03-23-acm-mustonlyhave/</loc><lastmod>2022-03-23T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/blog/2021-12-31-medical-diagnosis/</loc><lastmod>2021-12-31T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/blog_tags/medical-diagnosis/</loc><lastmod>2021-12-31T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/patterns/multicloud-gitops/</loc><lastmod>2021-12-11T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/industries/industrial/</loc><lastmod>2021-10-12T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/patterns/industrial-edge/</loc><lastmod>2021-10-12T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/industries/manufacturing/</loc><lastmod>2021-10-12T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/patterns/medical-diagnosis/</loc><lastmod>2021-01-19T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/patterns/industrial-edge/demo-script/</loc></url><url><loc>https://validatedpatterns.io/ci/</loc></url><url><loc>https://validatedpatterns.io/patterns/cockroachdb/</loc></url><url><loc>https://validatedpatterns.io/patterns/connected-vehicle-architecture/</loc></url><url><loc>https://validatedpatterns.io/contribute/</loc></url><url><loc>https://validatedpatterns.io/ci/internal/</loc></url><url><loc>https://validatedpatterns.io/patterns/kong-gateway/</loc></url><url><loc>https://validatedpatterns.io/learn/</loc></url><url><loc>https://validatedpatterns.io/patterns/multicloud-gitops-portworx/</loc></url><url><loc>https://validatedpatterns.io/other_products/portworx-enterprise/</loc></url><url><loc>https://validatedpatterns.io/search/</loc></url><url><loc>https://validatedpatterns.io/contribute/support-policies/</loc></url></urlset>
\ No newline at end of file
+<?xml version="1.0" encoding="utf-8" standalone="yes"?><urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9" xmlns:xhtml="http://www.w3.org/1999/xhtml"><url><loc>https://validatedpatterns.io/learn/about-validated-patterns/</loc></url><url><loc>https://validatedpatterns.io/patterns/coco-pattern/coco-pattern-azure-requirements/</loc></url><url><loc>https://validatedpatterns.io/contribute/contribute-to-docs/</loc></url><url><loc>https://validatedpatterns.io/patterns/coco-pattern/coco-pattern-getting-started/</loc></url><url><loc>https://validatedpatterns.io/patterns/emerging-disease-detection/edd-getting-started/</loc></url><url><loc>https://validatedpatterns.io/patterns/gaudi-rag-chat-qna/gaudi-rag-chat-qna-getting-started/</loc></url><url><loc>https://validatedpatterns.io/patterns/mlops-fraud-detection/mfd-getting-started/</loc></url><url><loc>https://validatedpatterns.io/patterns/multicloud-gitops-amx-rhoai/mcg-amx-rhoai-getting-started/</loc></url><url><loc>https://validatedpatterns.io/patterns/multicloud-gitops-amx/mcg-amx-getting-started/</loc></url><url><loc>https://validatedpatterns.io/patterns/multicloud-gitops-qat/mcg-qat-getting-started/</loc></url><url><loc>https://validatedpatterns.io/patterns/multicloud-gitops-sgx-hello-world/mcg-sgx-hello-world-getting-started/</loc></url><url><loc>https://validatedpatterns.io/patterns/multicloud-gitops-sgx/mcg-sgx-getting-started/</loc></url><url><loc>https://validatedpatterns.io/patterns/multicloud-gitops/mcg-getting-started/</loc></url><url><loc>https://validatedpatterns.io/patterns/ansible-edge-gitops-kasten/getting-started/</loc></url><url><loc>https://validatedpatterns.io/patterns/ansible-edge-gitops/getting-started/</loc></url><url><loc>https://validatedpatterns.io/patterns/devsecops/getting-started/</loc></url><url><loc>https://validatedpatterns.io/patterns/industrial-edge/getting-started/</loc></url><url><loc>https://validatedpatterns.io/patterns/medical-diagnosis-amx/getting-started/</loc></url><url><loc>https://validatedpatterns.io/patterns/medical-diagnosis/getting-started/</loc></url><url><loc>https://validatedpatterns.io/patterns/multicloud-gitops-portworx/getting-started/</loc></url><url><loc>https://validatedpatterns.io/patterns/openshift-ai/getting-started/</loc></url><url><loc>https://validatedpatterns.io/patterns/rag-llm-gitops/getting-started/</loc></url><url><loc>https://validatedpatterns.io/patterns/retail/getting-started/</loc></url><url><loc>https://validatedpatterns.io/patterns/travelops/getting-started/</loc></url><url><loc>https://validatedpatterns.io/patterns/mlops-fraud-detection/mfd-running-the-demo/</loc></url><url><loc>https://validatedpatterns.io/learn/about-pattern-tiers-types/</loc></url><url><loc>https://validatedpatterns.io/contribute/background-on-pattern-development/</loc></url><url><loc>https://validatedpatterns.io/patterns/medical-diagnosis-amx/cluster-sizing/</loc></url><url><loc>https://validatedpatterns.io/patterns/medical-diagnosis/cluster-sizing/</loc></url><url><loc>https://validatedpatterns.io/patterns/industrial-edge/factory/</loc></url><url><loc>https://validatedpatterns.io/patterns/rag-llm-gitops/gpu_provisioning/</loc></url><url><loc>https://validatedpatterns.io/patterns/multicloud-gitops-amx-rhoai/mcg-amx-rhoai-demo-script/</loc></url><url><loc>https://validatedpatterns.io/patterns/ansible-edge-gitops-kasten/installation-details/</loc></url><url><loc>https://validatedpatterns.io/patterns/ansible-edge-gitops/installation-details/</loc></url><url><loc>https://validatedpatterns.io/patterns/multicloud-gitops-amx/mcg-amx-managed-cluster/</loc></url><url><loc>https://validatedpatterns.io/patterns/multicloud-gitops-portworx/managed-cluster/</loc></url><url><loc>https://validatedpatterns.io/patterns/multicloud-gitops-qat/mcg-qat-managed-cluster/</loc></url><url><loc>https://validatedpatterns.io/patterns/multicloud-gitops-sgx-hello-world/mcg-sgx-hello-world-managed-cluster/</loc></url><url><loc>https://validatedpatterns.io/patterns/multicloud-gitops-sgx/mcg-sgx-managed-cluster/</loc></url><url><loc>https://validatedpatterns.io/patterns/multicloud-gitops/mcg-managed-cluster/</loc></url><url><loc>https://validatedpatterns.io/patterns/devsecops/devel-cluster/</loc></url><url><loc>https://validatedpatterns.io/patterns/retail/store/</loc></url><url><loc>https://validatedpatterns.io/learn/validated_patterns_frameworks/</loc></url><url><loc>https://validatedpatterns.io/learn/vp_openshift_framework/</loc></url><url><loc>https://validatedpatterns.io/learn/vp_structure_vp_pattern/</loc></url><url><loc>https://validatedpatterns.io/learn/vp_agof/</loc></url><url><loc>https://validatedpatterns.io/learn/vp_agof_config_controller/</loc></url><url><loc>https://validatedpatterns.io/patterns/industrial-edge/application/</loc></url><url><loc>https://validatedpatterns.io/patterns/retail/application/</loc></url><url><loc>https://validatedpatterns.io/patterns/multicloud-gitops-amx/mcg-amx-cluster-sizing/</loc></url><url><loc>https://validatedpatterns.io/patterns/multicloud-gitops-qat/mcg-qat-cluster-sizing/</loc></url><url><loc>https://validatedpatterns.io/patterns/multicloud-gitops-sgx-hello-world/mcg-sgx-hello-world-cluster-sizing/</loc></url><url><loc>https://validatedpatterns.io/patterns/multicloud-gitops-sgx/mcg-sgx-cluster-sizing/</loc></url><url><loc>https://validatedpatterns.io/patterns/multicloud-gitops/mcg-cluster-sizing/</loc></url><url><loc>https://validatedpatterns.io/patterns/ansible-edge-gitops-kasten/cluster-sizing/</loc></url><url><loc>https://validatedpatterns.io/patterns/ansible-edge-gitops/cluster-sizing/</loc></url><url><loc>https://validatedpatterns.io/patterns/multicloud-gitops-portworx/cluster-sizing/</loc></url><url><loc>https://validatedpatterns.io/patterns/retail/components/</loc></url><url><loc>https://validatedpatterns.io/patterns/multicloud-gitops-sgx-hello-world/mcg-sgx-hello-world-demo-script/</loc></url><url><loc>https://validatedpatterns.io/contribute/extending-a-pattern/</loc></url><url><loc>https://validatedpatterns.io/patterns/multicloud-gitops-amx-rhoai/mcg-amx-rhoai-bert-script/</loc></url><url><loc>https://validatedpatterns.io/learn/keyconcepts/</loc></url><url><loc>https://validatedpatterns.io/patterns/gaudi-rag-chat-qna/gaudi-rag-chat-qna-required-hardware/</loc></url><url><loc>https://validatedpatterns.io/patterns/devsecops/production-cluster/</loc></url><url><loc>https://validatedpatterns.io/patterns/ansible-edge-gitops-kasten/ansible-automation-platform/</loc></url><url><loc>https://validatedpatterns.io/patterns/ansible-edge-gitops/ansible-automation-platform/</loc></url><url><loc>https://validatedpatterns.io/contribute/creating-a-pattern/</loc></url><url><loc>https://validatedpatterns.io/patterns/multicloud-gitops-amx/mcg-amx-imperative-actions/</loc></url><url><loc>https://validatedpatterns.io/patterns/multicloud-gitops-qat/mcg-qat-imperative-actions/</loc></url><url><loc>https://validatedpatterns.io/patterns/multicloud-gitops-sgx-hello-world/mcg-sgx-hello-world-imperative-actions/</loc></url><url><loc>https://validatedpatterns.io/patterns/multicloud-gitops-sgx/mcg-sgx-imperative-actions/</loc></url><url><loc>https://validatedpatterns.io/patterns/multicloud-gitops/mcg-imperative-actions/</loc></url><url><loc>https://validatedpatterns.io/patterns/devsecops/secure-supply-chain-demo/</loc></url><url><loc>https://validatedpatterns.io/learn/quickstart/</loc></url><url><loc>https://validatedpatterns.io/patterns/gaudi-rag-chat-qna/gaudi-rag-chat-qna-troubleshooting/</loc></url><url><loc>https://validatedpatterns.io/patterns/industrial-edge/troubleshooting/</loc></url><url><loc>https://validatedpatterns.io/patterns/medical-diagnosis-amx/troubleshooting/</loc></url><url><loc>https://validatedpatterns.io/patterns/medical-diagnosis/troubleshooting/</loc></url><url><loc>https://validatedpatterns.io/patterns/retail/troubleshooting/</loc></url><url><loc>https://validatedpatterns.io/learn/importing-a-cluster/</loc></url><url><loc>https://validatedpatterns.io/learn/ocp-cluster-general-sizing/</loc></url><url><loc>https://validatedpatterns.io/patterns/devsecops/cluster-sizing/</loc></url><url><loc>https://validatedpatterns.io/patterns/industrial-edge/cluster-sizing/</loc></url><url><loc>https://validatedpatterns.io/patterns/retail/cluster-sizing/</loc></url><url><loc>https://validatedpatterns.io/patterns/medical-diagnosis-amx/ideas-for-customization/</loc></url><url><loc>https://validatedpatterns.io/patterns/medical-diagnosis/ideas-for-customization/</loc></url><url><loc>https://validatedpatterns.io/patterns/travelops/ideas-for-customization/</loc></url><url><loc>https://validatedpatterns.io/learn/infrastructure/</loc></url><url><loc>https://validatedpatterns.io/patterns/multicloud-gitops-amx-rhoai/mcg-amx-rhoai-managed-cluster/</loc></url><url><loc>https://validatedpatterns.io/patterns/ansible-edge-gitops-kasten/openshift-virtualization/</loc></url><url><loc>https://validatedpatterns.io/patterns/ansible-edge-gitops/openshift-virtualization/</loc></url><url><loc>https://validatedpatterns.io/learn/test-artifacts/</loc></url><url><loc>https://validatedpatterns.io/learn/using-validated-pattern-operator/</loc></url><url><loc>https://validatedpatterns.io/learn/clustergroup-in-values-files/</loc></url><url><loc>https://validatedpatterns.io/patterns/ansible-edge-gitops-kasten/veeam-kasten/</loc></url><url><loc>https://validatedpatterns.io/patterns/multicloud-gitops-amx-rhoai/mcg-amx-rhoai-cluster-sizing/</loc></url><url><loc>https://validatedpatterns.io/patterns/medical-diagnosis/demo-script/</loc></url><url><loc>https://validatedpatterns.io/patterns/multicloud-gitops-sgx/mcg-sgx-demo-script/</loc></url><url><loc>https://validatedpatterns.io/patterns/multicloud-gitops/mcg-demo-script/</loc></url><url><loc>https://validatedpatterns.io/patterns/travelops/demo-script/</loc></url><url><loc>https://validatedpatterns.io/patterns/multicloud-gitops-amx/mcg-amx-ideas-for-customization/</loc></url><url><loc>https://validatedpatterns.io/patterns/multicloud-gitops-qat/mcg-qat-ideas-for-customization/</loc></url><url><loc>https://validatedpatterns.io/patterns/multicloud-gitops-sgx-hello-world/mcg-sgx-hello-world-ideas-for-customization/</loc></url><url><loc>https://validatedpatterns.io/patterns/multicloud-gitops-sgx/mcg-sgx-ideas-for-customization/</loc></url><url><loc>https://validatedpatterns.io/patterns/multicloud-gitops/mcg-ideas-for-customization/</loc></url><url><loc>https://validatedpatterns.io/patterns/ansible-edge-gitops-kasten/ideas-for-customization/</loc></url><url><loc>https://validatedpatterns.io/patterns/ansible-edge-gitops/ideas-for-customization/</loc></url><url><loc>https://validatedpatterns.io/patterns/devsecops/ideas-for-customization/</loc></url><url><loc>https://validatedpatterns.io/patterns/industrial-edge/ideas-for-customization/</loc></url><url><loc>https://validatedpatterns.io/patterns/multicloud-gitops-portworx/ideas-for-customization/</loc></url><url><loc>https://validatedpatterns.io/patterns/retail/ideas-for-customization/</loc></url><url><loc>https://validatedpatterns.io/learn/workflow/</loc></url><url><loc>https://validatedpatterns.io/learn/secrets-management-in-the-validated-patterns-framework/</loc></url><url><loc>https://validatedpatterns.io/learn/vault/</loc></url><url><loc>https://validatedpatterns.io/learn/implementation/</loc></url><url><loc>https://validatedpatterns.io/learn/sandbox/</loc></url><url><loc>https://validatedpatterns.io/learn/tested/</loc></url><url><loc>https://validatedpatterns.io/learn/maintained/</loc></url><url><loc>https://validatedpatterns.io/patterns/multicloud-gitops-amx-rhoai/mcg-amx-rhoai-imperative-actions/</loc></url><url><loc>https://validatedpatterns.io/patterns/ansible-edge-gitops-kasten/troubleshooting/</loc></url><url><loc>https://validatedpatterns.io/patterns/ansible-edge-gitops/troubleshooting/</loc></url><url><loc>https://validatedpatterns.io/learn/values-files/</loc></url><url><loc>https://validatedpatterns.io/patterns/multicloud-gitops-amx-rhoai/mcg-amx-rhoai-ideas-for-customization/</loc></url><url><loc>https://validatedpatterns.io/learn/secrets/</loc></url><url><loc>https://validatedpatterns.io/learn/faq/</loc></url><url><loc>https://validatedpatterns.io/blog/2024-11-07-clustergroup-sequencing/</loc><lastmod>2024-11-07T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/blog/</loc><lastmod>2024-11-07T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/blog_tags/</loc><lastmod>2024-11-07T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/blog_tags/how-to/</loc><lastmod>2024-11-07T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/blog_tags/patterns/</loc><lastmod>2024-11-07T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/blog_tags/sequencing/</loc><lastmod>2024-11-07T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/blog_tags/subscriptions/</loc><lastmod>2024-11-07T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/</loc><lastmod>2024-11-07T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/patterns/ansible-edge-gitops-kasten/</loc><lastmod>2024-10-28T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/industries/chemical/</loc><lastmod>2024-10-28T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/industries/</loc><lastmod>2024-10-28T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/other_products/</loc><lastmod>2024-10-28T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/patterns/</loc><lastmod>2024-10-28T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/rh_products/red-hat-ansible-automation-platform/</loc><lastmod>2024-10-28T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/rh_products/red-hat-enterprise-linux/</loc><lastmod>2024-10-28T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/rh_products/red-hat-openshift-container-platform/</loc><lastmod>2024-10-28T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/rh_products/red-hat-openshift-data-foundation/</loc><lastmod>2024-10-28T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/rh_products/red-hat-openshift-virtualization/</loc><lastmod>2024-10-28T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/rh_products/</loc><lastmod>2024-10-28T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/other_products/veeam-kasten/</loc><lastmod>2024-10-28T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/blog/2024-10-12-disconnected/</loc><lastmod>2024-10-12T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/patterns/coco-pattern/</loc><lastmod>2024-10-03T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/industries/general/</loc><lastmod>2024-10-03T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/rh_products/red-hat-advanced-cluster-management/</loc><lastmod>2024-10-03T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/rh_products/red-hat-openshift-sandbox-containers/</loc><lastmod>2024-10-03T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/blog/2024-09-26-slimming-of-common/</loc><lastmod>2024-09-26T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/patterns/regional-dr/</loc><lastmod>2024-09-20T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/blog/2024-09-13-using-hypershift/</loc><lastmod>2024-09-13T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/blog/2024-08-30-push-secrets/</loc><lastmod>2024-08-30T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/patterns/rag-llm-gitops/</loc><lastmod>2024-07-25T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/rh_products/red-hat-openshift-gitops/</loc><lastmod>2024-07-25T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/blog/2024-07-19-write-token-kubeconfig/</loc><lastmod>2024-07-19T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/blog_tags/git/</loc><lastmod>2024-07-12T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/blog/2024-07-12-in-cluster-git/</loc><lastmod>2024-07-12T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/patterns/ansible-gitops-framework/</loc><lastmod>2024-06-13T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/patterns/gaudi-rag-chat-qna/</loc><lastmod>2024-06-01T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/rh_products/red-hat-openshift-ai/</loc><lastmod>2024-06-01T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/rh_products/red-hat-openshift-serverless/</loc><lastmod>2024-06-01T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/rh_products/red-hat-openshift-service-mesh/</loc><lastmod>2024-06-01T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/patterns/openshift-ai/</loc><lastmod>2024-04-22T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/rh_products/red-hat-pipelines/</loc><lastmod>2024-04-22T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/patterns/multicloud-gitops-amx-rhoai/</loc><lastmod>2024-02-27T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/patterns/multicloud-gitops-sgx-hello-world/</loc><lastmod>2024-02-20T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/patterns/multicloud-gitops-sgx/</loc><lastmod>2024-02-09T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/rh_products/red-hat-elasticsearch/</loc><lastmod>2024-02-09T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/rh_products/red-hat-jaeger-distributed-tracing/</loc><lastmod>2024-02-09T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/rh_products/red-hat-kiali/</loc><lastmod>2024-02-09T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/rh_products/red-hat-service-mesh/</loc><lastmod>2024-02-09T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/patterns/travelops/</loc><lastmod>2024-02-09T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/blog/2024-02-07-hcp-htpasswd-config/</loc><lastmod>2024-02-07T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/blog_tags/announce/</loc><lastmod>2024-02-02T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/blog/2024-03-05-intel-accelerated-patterns/</loc><lastmod>2024-02-02T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/blog/2024-01-26-more-secrets-options/</loc><lastmod>2024-01-26T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/blog_tags/secrets/</loc><lastmod>2024-01-26T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/blog/2024-01-16-deploying-mcg-with-cisco-flashstack-portworx/</loc><lastmod>2024-01-16T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/blog/2023-12-20-private-repos/</loc><lastmod>2023-12-20T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/blog/2023-12-15-understanding-namespaces/</loc><lastmod>2023-12-15T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/blog_tags/nutanix/</loc><lastmod>2023-12-04T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/blog/2023-12-05-nutanix-testing/</loc><lastmod>2023-12-04T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/blog/2023-12-01-new-pattern-tiers/</loc><lastmod>2023-12-01T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/blog/2023-11-17-argo-configmanagement-plugins/</loc><lastmod>2023-11-17T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/blog_tags/devops/</loc><lastmod>2023-11-17T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/blog_tags/devsecops/</loc><lastmod>2023-11-17T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/blog_tags/gitops/</loc><lastmod>2023-11-17T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/blog_tags/openshift-platform-plus/</loc><lastmod>2023-11-17T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/blog_tags/pipelines/</loc><lastmod>2023-11-17T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/other_products/aws-controller-for-kubernetes/</loc><lastmod>2023-11-15T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/patterns/hypershift/</loc><lastmod>2023-11-15T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/industries/infrastructure/</loc><lastmod>2023-11-15T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/rh_products/red-hat-multicluster-engine/</loc><lastmod>2023-11-15T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/industries/financial-services/</loc><lastmod>2023-11-12T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/patterns/mlops-fraud-detection/</loc><lastmod>2023-11-12T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/rh_products/red-hat-openshift-data-science/</loc><lastmod>2023-11-12T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/patterns/medical-diagnosis-amx/</loc><lastmod>2023-10-10T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/industries/medical/</loc><lastmod>2023-10-10T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/patterns/multicloud-gitops-amx/</loc><lastmod>2023-10-05T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/patterns/multicloud-gitops-qat/</loc><lastmod>2023-10-05T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/patterns/emerging-disease-detection/</loc><lastmod>2023-09-23T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/rh_products/red-hat-amq-streams/</loc><lastmod>2023-09-23T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/rh_products/red-hat-single-sign-on/</loc><lastmod>2023-09-23T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/rh_products/red-hat-amq/</loc><lastmod>2022-12-08T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/industries/retail/</loc><lastmod>2022-12-08T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/patterns/retail/</loc><lastmod>2022-12-08T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/blog_tags/acs/</loc><lastmod>2022-12-01T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/blog/2022-12-01-multicluster-devsecops/</loc><lastmod>2022-12-01T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/blog_tags/quay/</loc><lastmod>2022-12-01T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/blog_tags/security/</loc><lastmod>2022-12-01T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/blog/2022-11-20-argo-rollouts/</loc><lastmod>2022-11-03T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/blog_tags/acm/</loc><lastmod>2022-10-12T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/blog/2022-10-12-acm-provisioning/</loc><lastmod>2022-10-12T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/blog_tags/provisioning/</loc><lastmod>2022-10-12T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/blog_tags/openshift/</loc><lastmod>2022-09-02T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/blog_tags/route/</loc><lastmod>2022-09-02T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/blog/2022-09-02-route/</loc><lastmod>2022-09-02T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/blog_tags/validated-pattern/</loc><lastmod>2022-09-02T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/blog/2022-08-24-clustergroups/</loc><lastmod>2022-08-24T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/blog_tags/ansible-edge-gitops/</loc><lastmod>2022-07-15T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/blog/2022-07-15-push-vs-pull/</loc><lastmod>2022-07-15T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/blog/2022-06-30-ansible-edge-gitops/</loc><lastmod>2022-06-30T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/patterns/ansible-edge-gitops/</loc><lastmod>2022-06-08T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/patterns/devsecops/</loc><lastmod>2022-06-08T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/rh_products/red-hat-advanced-cluster-security/</loc><lastmod>2022-06-08T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/rh_products/red-hat-quay/</loc><lastmod>2022-06-08T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/blog_tags/multi-cloud-gitops/</loc><lastmod>2022-03-30T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/blog/2022-03-30-multicloud-gitops/</loc><lastmod>2022-03-30T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/blog_tags/xray/</loc><lastmod>2022-03-30T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/blog/2022-03-23-acm-mustonlyhave/</loc><lastmod>2022-03-23T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/blog/2021-12-31-medical-diagnosis/</loc><lastmod>2021-12-31T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/blog_tags/medical-diagnosis/</loc><lastmod>2021-12-31T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/patterns/multicloud-gitops/</loc><lastmod>2021-12-11T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/industries/industrial/</loc><lastmod>2021-10-12T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/patterns/industrial-edge/</loc><lastmod>2021-10-12T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/industries/manufacturing/</loc><lastmod>2021-10-12T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/patterns/medical-diagnosis/</loc><lastmod>2021-01-19T00:00:00+00:00</lastmod></url><url><loc>https://validatedpatterns.io/patterns/industrial-edge/demo-script/</loc></url><url><loc>https://validatedpatterns.io/ci/</loc></url><url><loc>https://validatedpatterns.io/patterns/cockroachdb/</loc></url><url><loc>https://validatedpatterns.io/patterns/connected-vehicle-architecture/</loc></url><url><loc>https://validatedpatterns.io/contribute/</loc></url><url><loc>https://validatedpatterns.io/ci/internal/</loc></url><url><loc>https://validatedpatterns.io/patterns/kong-gateway/</loc></url><url><loc>https://validatedpatterns.io/learn/</loc></url><url><loc>https://validatedpatterns.io/patterns/multicloud-gitops-portworx/</loc></url><url><loc>https://validatedpatterns.io/other_products/portworx-enterprise/</loc></url><url><loc>https://validatedpatterns.io/search/</loc></url><url><loc>https://validatedpatterns.io/contribute/support-policies/</loc></url></urlset>
\ No newline at end of file