The Phalanx documentation describes the process for adding a new service to the Rubin Science Platform (RSP).
In summary, it requires creating a Helm chart in the charts repository with the default configuration for the service and an Argo CD application in the phalanx repository with a small wrapper chart to hold the deployment configuration for each RSP environment.
In this RFC, we propose creating the RSP Helm charts directly in the phalanx repository and eliminating the charts repository to simplify the development workflow.
Why did we start with two repositories?
The charts repository predates the phalanx repository, which was created to store the RSP deployment configuration managed by Argo CD and scripts to bootstrap an RSP installation.
Argo CD supports several tools in which the Kubernetes manifests for an RSP service can be defined, including Helm, Kustomize, and others. See also SQR-035: Deployment engineering for Kubernetes-based services.
Initially, because of the flexibility offered by Argo CD, we decided to keep the charts repository and use it to develop the RSP Helm charts. However, all RSP services use Helm today, and Kustomize services with multi-environment configuration are not currently supported.
What is the current developer workflow?
Every time we want to add a service developed by ourselves, for example, squareone, we create a new Helm chart in the charts repository. Then we add the Argo CD application and the wrapper chart with the multi-environment configuration to the phalanx repository.
A GitHub Action in the charts repository automatically publishes the Helm chart each time a new version is merged to master, but we still need an additional commit in the phalanx repository to reference the new version.
We have a similar workflow to add third-party Helm charts that require additional Kubernetes resources not part of the upstream chart (for example, a VaultSecret resource).
All Helm charts in the charts repository are related to the RSP. Sometimes, they are not deployed as part of the RSP like neophile, for example, but they are still essential to the RSP infrastructure.
Working with two repositories may cause ambiguity. For example, we might add extra Kubernetes resources to the chart in the charts repository or directly to the wrapper chart in the phalanx repository.
An advantage of publishing a Helm chart is that it can be shared with multiple RSP services. However, today's only example of a shared chart is the strimzi-registry-operator.
We use helm-docs to generate documentation for the RSP Helm charts. Currently, this documentation lives in the charts repository, because of the chart default configuration (values.yaml).
What changes with the new organization?
- We propose developing Helm charts for RSP services directly in the phalanx repository. They essentially become the wrapper charts under the services/ folder. These charts are not published anymore.
- We propose creating a new charts/ folder in the phalanx repository to develop and publish charts that are not deployed as part of the RSP or charts that are shared among RSP services.
- With that, we can run helm-docs in the phalanx repository.
Note that because we are not publishing these charts anymore, the version and other chart metadata become irrelevant.
Proof of concept
We have used sasquatch as proof of concept and noticed the following additional advantages with the new organization:
- The default configuration (values.yaml) and the environment-specific configuration (values-*.yaml) are now in the same repository and folder. Only a small change in the Argo CD application definition was required for the environment-specific configuration to take precedence over the default configuration.
- We tried a simplified template for the chart documentation which includes the chart name, description, dependencies, and default values.
The initial reason for having the charts repository doesn't exist anymore, and this reorganization simplifies the development workflow by keeping the RSP Helm charts in the phalanx repository along with the RSP deployment configuration.