Support for multiple charts in single release (similar to alias in helm)

[imdhruva]

Currently we map single release in helmfile by using helm sub charts i.e.

subchart1: worker-type1
subchart2: worker-type2
chart1:
  subchart1-alias1:
    overide-variables1
  subchart2-alias1:
    overide-variables1
  subchart2-alias2:
    overide-variables2

where a chart refers to a subchart multiple times by using aliases in requirements.yaml. We then manage the deployment of chart1 by mapping it to a release in helmfile.

While this pattern works it is very difficult to iterate over this pattern. Figure this scenario:

• we want to update the subchart1 - for every end-to-end test on this we will need to update the chart1 to point to the new version of subchart1 and then update helmfile to point to new versions of chart1.
• we want the release to map directly to an application - for every application we want to have a single release so we can easily map and graph the unique names. while we can still work-around this by using a unique label across a single helmfile declaring multiple releases - but that would not be as consistent.

An ideal solution would be to flatten the structure and have no subchart and let helmfile manage the alias declaration. Effectively in helmfile release we call something like:

helmDefaults:
  tillerNamespace: {{ .Environment.Values.tiller }}
  kubeContext: {{ .Environment.Values.kubectx }}

environments:
  env1:
    values:
    - ../../envs/env1.yaml
  env2:
    values:
    - ../../envs/env2.yaml

releases:
  - name: app 
    namespace: {{ .Environment.Values.namespace }}
    charts:
    - alias: app-worker1
       chart: repo-name/app-worker1
       version: 0.1.4
    - alias: app-worker2
       chart: repo-name/app-worker1
       version: 0.1.4
    secrets:
      - secrets/app.{{ .Environment.Values.env }}.yaml
    values:
      - values/app.yaml.gotmpl

--app.yaml.gotmpl

app-worker1:
  override-values:
    aa: 112asas
    bb: 121212
app-worker2:
  override-values:
  cc: 12412
  dd: 124sdf

It would be very convenient to have a feature similar to helm alias in helmfile so we can call multiple instances of a single chart.

[mumoshu]

@imdhruva Hey!

I'm still trying to understand. What would be benefits of that over just creating separate releases for app=chart1 , app-worker1=app-worker and app-worker2=app-worker?

Also in your example you seem to have missed a primary chart under charts, right? I might be confused but it looks odd that there are only sub-charts in your example.

Or did you imply that the primary chart can be an empty one with requirements.yaml that should be generated by helmfile?

[imdhruva]

sorry for the confusion and many thanks for the prompt response.

I'm still trying to understand. What would be benefits of that over just creating separate releases for app=chart1 , app-worker1=app-worker and app-worker2=app-worker?

we want every application to be a single release for easier management from helm. For example if in the deployment pipeline the release fail we can directly call helm rollback {{ .Release.Name }} (with some intelligence in the script re: identifying which release failed); where {{ .Release.Name }} is same as the application name. Similarly there are lot of helm functions that can map to a single application release.

Also in your example you seem to have missed a primary chart under charts, right? I might be confused but it looks odd that there are only sub-charts in your example.

Or did you imply that the primary chart can be an empty one with requirements.yaml that should be generated by helmfile?

Long answer short : Parent chart does not do any templating it is only is only used to for calling multiple instances of subchart1 and subchart2 (it does declare some default values but helmfile is strong enough to make us address that in helmfile itself). Detail: currently we are packaging the application into one release. So for example one application has different components each of which correspond to different charts we just need a capability to say Release X needs x number of component1 and y number of component2. To be more specific every application is packaged into an api component and a kcl component - api component which has ingress/service/secrets/deployment/etc. whereas kcl is just a deployment. Now one application can as for 1 of an api component that needs 5 kcl component - now we package all of them into 1 release called app1. The helm chart map would look something like this :

parentchart -> app -------> subchart1
                                 |
                                 | --> subchart2 (alias a)
                                 | --> subchart2 (alias b)

we call multiple instances of subchart2 by calling aliasing in the requirements.yaml file.
Obviously this pattern is not ideal if we want to perform an update in the base chart (subchart1 or subchart2).
So the idea here is to flatten the structure - get rid of parentchart in the figure above and only use subcharts directly from helmfile.