$ git checkout my-branch mainIdeas 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.
Customizing 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.
Follow this procedure to split the config-demo application across the hub and regional clusters:
- Ensure you are in your locally created feature branch by running the following command: 
- Run the following commands to create the - charts/hubdirectory (the region directory already exists):- $ mkdir -p charts/hub
- Copy the - charts/all/config-demoto- charts/hub/config-demoby running the following command:- $ cp -r charts/all/config-demo charts/hub/config-demo
- Copy the - charts/all/config-demoto- charts/region/config-demoby running the following command:- $ cp -r charts/all/config-demo charts/region/config-demo
- Edit - config-demo-cm.yamlin- charts/hub/config-demo/templatesadd the line- This is the hub cluster patched version via git:- </head> <body> <h1> This is the hub cluster patched version via git <br> Hub Cluster domain is '{{ .Values.global.hubClusterDomain }}' <br> Pod is running on Local Cluster Domain '{{ .Values.global.localClusterDomain }}' <br> </h1> <h2> The secret is <a href="/secret/secret">secret</a>
- Edit - config-demo-cm.yamlin- charts/hub/config-demo/templatesadd the line- This is the hub cluster patched version via git:- </head> <body> <h1> This is the hub cluster patched version via git <br> Hub Cluster domain is '{{ .Values.global.hubClusterDomain }}' <br> Pod is running on Local Cluster Domain '{{ .Values.global.localClusterDomain }}' <br> </h1> <h2> The secret is <a href="/secret/secret">secret</a>
- In the root directory of your repository, edit the - values-hub.yamlfile and modify the path as follows:- config-demo: name: config-demo namespace: config-demo project: config-demo path: charts/hub/config-demo
- In the root directory of your repository, edit the - values-group-one.yamlfile and modify the path as follows:- config-demo: name: config-demo namespace: config-demo project: config-demo path: charts/region/config-demo
- Add the changes to the staging area by running the following command: - $ git add .
- Commit the changes by running the following command: - $ git commit -m "test another change"
- Push the change to the remote repository by running the following command: - $ git push origin my-branch
ArgoCD will apply the change to the config-demo application.
Verify that the update to the config-demo application is successfully applied to your hub cluster as follows:
- In the OpenShift console associated with your hub cluster go to the Networking → Routes menu options. 
- From the Project: drop down select the config-demo project. 
- Click the Location URL. This should reveal the following: - This is the hub cluster patched version via git Hub Cluster domain is 'apps.kevstestcluster.aws.validatedpatterns.io' Pod is running on Local Cluster Domain 'apps.kevstestcluster.aws.validatedpatterns.io' The secret is secret
Verify that the update to the config-demo application is successfully applied to your managed cluster as follows:
- In the OpenShift console associated with your hub cluster go to the Networking → Routes menu options. 
- From the Project: drop down select the config-demo project. 
- Click the Location URL. This should reveal the following: - This is the managed cluster Hub Cluster domain is 'apps.kevstestcluster.aws.validatedpatterns.io' Pod is running on Local Cluster Domain 'apps.ci-ln-cf2475b-76ef8.aws-2.ci.openshift.org' The secret is secret
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.
