The Slimming of Common

by Michele Baldessari

September 26, 2024

patterns how-to

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 & 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's repository
gh repo clone validatedpatterns/multicloud-gitops

# In the patterns' repository add the common remote
cd multicloud-gitops
git remote add -f common https://github.com/validatedpatterns/common

# Create a 'slimming' 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/<…> 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: "."
      chartVersion: dev-branch
      repoURL: https://github.com/myorg/acm-chart