Proposal: New Plugin for Generic Helm Chart Deployment

[prodanlabs]

Description

I personally think it is possible to create a generic helm plugin to deploy the application of helm charts
for example

- name: helm-demo
  plugin: helm-charts-plugin
  options:
    #  helm charts address
    repo: YOUR_HELM_CHARTS
    namespace: K8S_NAMESPACE
    # helm charts deployment parameters
    helm_options: "parameter1","parameter2"

I don't know if anyone is interested in this feature :）

[daniel-hutao]

Summary

Thanks for your proposal, it's a great idea. I'd like to give a design here.

Why Are There So Many helm-type Plugins now?

As you all know, we already have a lot of plugins implemented through the helm SDK. Maybe you have a question here: Why don't you implement all helm-type plugin deployments through a plugin names helm-generic plugin? Let me tell you.

If you simply deploy a tool through helm install command, you don't even need dtm, you just use helm cli directly. So what is the purpose of implementing a lot of helm-style plugins?

Maybe you already get it, we definitely need to do some extra work for it. For example, a tool may need to do Pre-configuration with storage before passing helm install. Or some cleanup needs to be done after helm uninstall. Or some additional robustness processing is required during the installation process.

In conclusion, we believe that the deployment of most helm charts is not a simple one-line command, and the additional operations required for these deployment processes are also different. So we have developed separate plugins for the deployment of each helm-style tool.

What Can The helm-generic Plugin Do?

When a chart is "unpopular", or the chart is NOT open source, we cannot know the deployment logic of the chart in advance. We only know that it can be deployed by helm install. For the deployment of such "private" tools/projects/applications, what we can do is to provide a "generic" support only, and allowing users to manage such tools in a unified way.

Design

• config.yaml

tools:
- name: helm-generic
  instanceID: YOUR_INSTANCE_ID
  options: # See the `internal/pkg/plugin/common/helm/helm.go` for more details.
    create_namespace: true
    repo:
      name: YOUR_REPO_URL
      url: YOUR_CHART_URL
    chart:
      chart_name: YOUR_CHART_NAME
      release_name: YOUR_RELEASE_NAME
      namespace: YOUR_RELEASE_NAMESPACE
      wait: true
      timeout: YOUR_DEPLOY_TIMEOUT
      upgradeCRDs: true
      values_yaml: |
        FOO: BAR

• e.g.

If we use the helm-generic plugin to install ArgoCD:

tools:
- name: helm-generic
  instanceID: argocd-ins1
  options:
    create_namespace: true
    repo:
      name: argo
      url: https://argoproj.github.io/argo-helm
    chart:
      chart_name: argo/argo-cd
      release_name: argocd
      namespace: argocd
      wait: true
      timeout: 10m
      upgradeCRDs: true

• other logic

At present, our deployment of ArgoCD does not have much additional logic processing except helm install, so the logic of this generic plugin will be very similar to ArgoCD, you can refer to the logic inside internal/pkg/plugin/argocd.

Remember to use dtm develop create-plugin --name=helm-generic to scaffold it.

[prodanlabs]

Sorry, I don't have time right now. If it affects the version plan may need to be assigned to someone else.
I might have time next month.

[prodanlabs]

Hi @daniel-hutao ，I was thinking, it seems that the kubeprometheus plugin can also be turned into a generic helm plugin.