- 
                Notifications
    
You must be signed in to change notification settings  - Fork 198
 
Description
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: 32000Config 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: 32000Because 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: 32000For 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.