Open jkotalik opened 2 years ago
One open question I'd like to add - do we want to go the Bicep extensibility route for this? Or do we want to integrate this with UCP and keep the Bicep integration minimal.
We are going to discuss with the ARM team as well, there was interest in ownership of the helm provider by them.
Overview
With Radius environments starting to become more feature rich, we would like to be able to describe infrastructure components as part of the environment as well. For example:
The common way to install these pieces is through a Helm chart. As part of
rad env init/rad install
, we already use the helm client to install dapr and contour. Being able to specify it outside ofrad env init
would be useful in setting up a cluster.We are motivated to remove default pieces like dapr and contour as part of default installations in the future for Radius (https://github.com/project-radius/radius/issues/2952). This will improve the footprint of Radius on a Kubernetes cluster and allow people to specify which exact version of these dependencies to use, rather than the one baked into Radius.
To enable this, being able to specify helm resources in bicep would be a great stepping-stone for this functionality.
User scenarios
As an infrastructure engineer, I would like to specify my companies helm chart implementation of MongoDB to ensure that all engineers are using the compliant version of MongoDB.
As a Dapr developer, I'd like to control the version of dapr installed in the cluster rather than having Radius install it for me.
As an infrastructure engineer, I'd like to enforce specific versions for different environment components based on the required version
Proposal
There are two main pieces that need to be added here:
Helm chart support in bicep
To start with, we should add support for helm releases, which allows for charts to be installed on a cluster.
This is effectively a minimal set of properties for a helm chart. We can add more as we go (wait, repository certificate authorization, timeout, etc.). For inspiration, see https://github.com/hashicorp/terraform-provider-helm/blob/main/helm/resource_release.go.
Open questions:
Tasks
Helm chart support in the Deployment Engine
To support the helm extensibility provider, it will be a simple change to add the route to the helm provider in the deployment engine and make sure request are routed to it for the import.
Tasks
Helm chart support as a bicep extensibility provider
The helm chart bicep extensibility provider will need to be written in golang due to Helm SDK's lack of support for C#. This will require using the extensibility swagger defined here to implement the extensibility API contract in golang.
From there, it will be a fairly straightforward invocation of the helm client APIs. We already do that today for many client-side things: https://github.com/project-radius/radius/blob/main/pkg/cli/helm/contourclient.go.
Tasks
AB#3979