Design decision: Packaging and orchestrating components and canvas

[LesterThomas]

Description

At present the reference implementation for both the ODA Canvas and Components uses Helm. This issue is to raise a formal decision to define the correct target approach and to consider alternatives like Terraform/OpenTofu.

The decision should make a separate recommendation for the Canvas and Components. The decision could be to use Helm, Terraform/OpenTofu or both (e.g. to install the Canvas with a Terraform script that install different modules using Helm); It can also consider other options.

Please use this issue to discuss ideas, options and opinions and we will formally document the decision in the Decision Log.

[gusjer]

Helm has become the de facto standard to package Kubernetes applications, being far from ideal, but it's better than alternatives like Kustomize, which already have their own downsizes and advantages.

We have to tell apart the Helm as a way to package (the Helm charts) from the Helm tool to deploy those packages.

Most of the software deployed in Kubernetes is done by helm charts; we have to be in a solid position to move apart from this and do things differently.

Terraform is mainly used to manage infrastructure declaratively; it also can install Helm Charts in clusters; we have used it in that way, but primarily for expendable environments for POCs. Application lifecycle management could be better. AWS in a blueprint project for creating a populated EKS cluster followed that approach, and they found that it didn't work in the long run terraform-aws-eks-blueprints

In a previous weekly call, someone questioned using GitOps as a paradigm for deploying things into Kubernetes. There are some tools for that, like ArgoCD or Flux that we should take into account, and they support Helm Charts as a source.

[csotiriou]

Hello,

Allow me to also provide input to this.

The current method of installation is here, https://github.com/tmforum-oda/oda-canvas/tree/master/installation, and it involves several sequential steps to install the canvas with Helm. There are also some prerequisites (such as Istio, which can be installed with helm as well).

My proposal would not be to ditch Helm, but to use it with Terraform. I propose creating terraform scripts to automate the current procedure with Helm Charts while reusing the current charts as intended to be reused, and not changing the current Helm chart structure. In short, I propose a wrapper on top of the current helm charts.

We currently use this method to set up our development Kubernetes environments locally and has allowed us to experiment with different infrastructures with ease since we are setting it up and tearing it down locally several times per day. We have tried using Makefiles, but state management is sub-par compared to Terraform.

Additional benefits

• Avoid "works on my machine" scenarios, as other things also need to be installed.
• Completely automate installation and uninstallation (using terraform destroy) which will make it much easier to set up new canvas reference implementations with just one command.
• Easier customizations - terraform variables will allow customizing properties in deploy time, so it's easier to provide a "self-documenting" solution.

For a project like this reference implementation, I believe it's good automation to be added on top of the existing solution.