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.

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:
```
$ git checkout my-branch main
```
Run the following commands to create the charts/hub directory (the region directory already exists):
```
$ mkdir -p charts/hub
```
Copy the charts/all/config-demo to charts/hub/config-demo by running the following command:
```
$ cp -r charts/all/config-demo charts/hub/config-demo
```
Copy the charts/all/config-demo to charts/region/config-demo by running the following command:
```
$ cp -r charts/all/config-demo charts/region/config-demo
```

Edit config-demo-cm.yaml in charts/hub/config-demo/templates add 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.yaml in charts/hub/config-demo/templates add 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.yaml file 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.yaml file 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.