Skip to content

🍀 Proposal: Merge All Helm Style Plugins into One Plugin #1194

@daniel-hutao

Description

@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.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions