🍀 Proposal: Merge All Helm Style Plugins into One Plugin

[daniel-hutao]

What Would You Like to Add? Why Is This Needed?

Now we have many plugins that deploy tools through Helm only. The main differences between them are values.yaml configuration. What's more? "Namespace, name, chartUrl, etc.". Deploying more and more tools by Helm may not reflect the value of DevStream, but rather increase the complexity of DevStream and increase our maintenance cost.

We didn't do much work on the Helm, especially the differential configuration for different tools upon the Helm. Our configuration is mainly passed through values.yaml. If we consider values.yaml as a configuration item, all these plugins are actually very similar and maybe we can merge them into one plugin.

Design

Add a new plugin named "helm-installer". Maybe we can do some modifications with "helm-generic" plugin, and rename it to "helm-installer".

Old Config with jenkins Plugin

tools:
- name: jenkins
  instanceID: default
  dependsOn: [ ]
  options:
    repo:
      name: jenkins
      url: https://charts.jenkins.io
    chart:
      chartPath: ""
      chartName: jenkins/jenkins
      version: ""
      namespace: jenkins
      wait: true
      timeout: 5m
      upgradeCRDs: true
      valuesYaml: |
        persistence:
          storageClass: ""
        serviceAccount:
          create: true
          name: jenkins
        controller:
          adminUser: "admin"
          adminPassword: "changeme"
          serviceType: NodePort
          nodePort: 32000

Config with helm-installer Plugin

• default config

tools:
- name: helm-installer
  instanceID: default
  dependsOn: [ ]
  options:
    valuesYaml: ""
    valuesYamlPath: ""
    repo:
      name: ""
      url: ""
    chart:
      chartPath: ""
      chartName: ""
      version: ""
      namespace: ""
      wait: true
      timeout: 5m
      upgradeCRDs: true
      valuesYaml: ""

How to Use the helm-installer Plugin?

• We give users the minimal configuration below if they want to deploy Jenkins:

tools:
- name: helm-installer
  instanceID: jenkins-001
  dependsOn: [ ]
  options:
    valuesYaml: |
      serviceAccount:
        create: true
        name: jenkins
      controller:
        adminUser: "admin"
        adminPassword: "changeme"
        serviceType: NodePort
        nodePort: 32000

Because the instanceID contains "jenkins", helm-installer could set some default config items and generate the new config as below:

tools:
- name: helm-installer
  instanceID: jenkins-001
  dependsOn: [ ]
  options:
    valuesYaml: ""
    valuesYamlPath: ""
    repo:
      name: jenkins
      url: https://charts.jenkins.io
    chart:
      chartPath: ""
      chartName: jenkins/jenkins
      version: ""
      namespace: jenkins
      wait: true
      timeout: 5m
      upgradeCRDs: true
      valuesYaml: |
        serviceAccount:
          create: true
          name: jenkins
        controller:
          adminUser: "admin"
          adminPassword: "changeme"
          serviceType: NodePort
          nodePort: 32000

For most users, it may be enough for them to read "Minimal Configuration", which is much easier to get started.

Instead of searching for multiple plugins and studying multiple documents, users can start with the helm-installer documentation, which tells them everything they need to know to deploy each tool.

Anything else

After this refactoring, using the dtm deploy tools might be simpler than Helm. For example, without the need to perform operations such as helm add, helm upgrade, users have a reason to use dtm when deploying tools.

In short, the main value of dtm is perhaps not in the deployment of the tools, but in the best practice configuration, integration, and other features. Let's take the focus off of "deployment" and acknowledge that dtm has little advantage over Helm in "tools deployment", and perhaps it'll get better results.

[steinliber]

LGTM

[IronCore864]

I have a proposal, where the following use cases should be supported by the generic helm-installer plugin:

• minimum config: the simplest conf that can be used
• override default values
• override values file (either by specifying a file path or the content)
• a combination of the above

Minimum Config

Example:

tools:
- name: helm-installer
  instanceID: jenkins
  dependsOn: [ ]

The purpose is for users to get started ASAP, with a very short config file.

In this case, we can use a lot of default values, such as:

• chart repo name: jenkins
• chart repo url: https://charts.jenkins.io
• use default values.yaml file from the chart
• other options: namespace: jenkins, wait: true, timeout 5m (etc., all the default values from jenkins plugin)

Override Default Options

Example:

tools:
- name: helm-installer
  instanceID: jenkins
  dependsOn: [ ]
  options:
    repo:
      name: jenkins
      url: https://charts.jenkins.io
    chart:
      chartPath: ""
      chartName: jenkins/jenkins
      version: ""
      namespace: jenkins
      wait: true
      timeout: 5m
      upgradeCRDs: true

The purpose is for users to adjust some common stuff, like chart repo name, or use a self-hosted chart repo URL, update timeout, etc.

Override Values File - Method 1 - File Content

tools:
- name: helm-installer
  instanceID: jenkins
  dependsOn: [ ]
  options:
    valuesYaml: |
      serviceAccount:
        create: true
        name: jenkins
      controller:
        adminUser: "admin"
        adminPassword: "changeme"
        serviceType: NodePort
        nodePort: 32000

The upside is there is only one file, no need to maintain another values file.

Override Values File - Method 2 - File Path

tools:
- name: helm-installer
  instanceID: jenkins
  dependsOn: [ ]
  options:
    valuesFile: "./values.yaml"

The upside is, the tools conf is short, and values file can be copy-pasted directly from a helm chart without editing indentations.

Putting Them All Together

Maximum conf, but also maximum flexibility:

tools:
- name: helm-installer
  instanceID: jenkins
  dependsOn: [ ]
  options:
    repo:
      name: jenkins
      url: https://charts.jenkins.io
    chart:
      chartPath: ""
      chartName: jenkins/jenkins
      version: ""
      namespace: jenkins
      wait: true
      timeout: 5m
      upgradeCRDs: true
    valuesFile: "./values.yaml"

[daniel-hutao]

@IronCore864 How about we unify the valuesFile and valuesYaml?

valuesYaml: "./values.yaml"

valuesYaml: |
  foo: bar

[daniel-hutao]

About the minimum config, I have 2 ideas here:

tools:
- name: helm-installer
  instanceID: jenkins

vs

tools:
- name: helm-installer
  instanceID: jenkins
  dependsOn: [ ]
  options: null

[daniel-hutao]

final edition:

tools:
- name: helm-installer
  instanceID: argocd-001
  dependsOn: [ ]
  options:
    repo:
      name: ""
      url: ""
    chart:
      chartPath: ""
      chartName: ""
      version: ""
      namespace: ""
      wait: true
      timeout: 10m
      upgradeCRDs: true
    valuesYaml: ""