independent version controlled helm values file

[perezjasonr]

Summary

followup on #2719 reopening this proposal. The author closed it but I disagree with the conclusion and believe this should still be pursued.

Motivation

To not allow the values file to be independently version controlled and checked into git in my opinion goes against the spirit of gitOps and forces design that is not ideal. In abandoning this proposal you closely couple the snowflake values/desired results of a single install to the chart itself.

This means either

a) for every given set of values files for an install the entire helm chart has to be replicated just for the values file.
or
b) the helm chart itself requires every possible desired values file preexisting within it.

so if I have three environments managed by 3 teams, but all three of those teams can reference a chart I designed, this means either all 3 of these teams must replicate the entire chart and modify it uniquely for their scenario even though I've given read/pull access to the chart and their argocd instance can reference it directly. Why do that when they can reference the chart and check in just the values?

or the reverse:
for each of these 3 teams I have to preload their values files in my chart. so they can update it, I now have to give them push/write access to my repo, or they have to tell me what they want if thats not their role and I have to add it.

Furthermore this seems to be intentional with helm. With helm, we can reference a chart, designed by someone else and version control our values file. Not allowing this takes away an option we have with helm itself although I admit having the inline values in the app object helps bridge that gap...but an independent values file route can be used both by someone just using regular helm AND someone using argocd.

In my mind decoupling the two is superior in many ways...maybe not every way, but many.
Indeed, this is a design choice and I think you should do w/e works best for your situation but I think version controlling the values file independently should at least be an option, alongside having the inline values of the argo app object, or cloning the entire chart and putting your own values file in it. Right now we don't have that option.

Proposal

same as 2719 something like this:

Proposal

...
  source:
    repoURL: https://kubernetes-charts.storage.googleapis.com
    chart: my-chart
    targetRevision: 1.0.0
    helm:
      valuesRepo: https://gitlab.com/someproject/path.git
      valuesFiles:
        - values/some/value.yaml

[blacksd]

We're in the middle of a software selection process, and this, coupled with the lack of an efficient solution for the secrets management (or robust integration with a project like SOPS or Vault that can supply it) is one of the major show stoppers.

From my perspective, asking to version the values together with the charts is not just an antipattern, it's a plain wrong choice: I have to be able to version my configuration and my charts following two independent paths.

[eytanhanig]

Not being able to separate them is also a security risk. We want developers to be able to self-manage environment variables and CI/CD to update and auto-commit image tags when new images are built without giving either write-access to more sensitive parts of our charts and values files.

[JulienBreux]

Hi !

I agree with that!

I've the same problem, but I've discover that:

https://github.com/argoproj/argo-cd/blob/master/docs/operator-manual/project.yaml#L14-L15

It's not a way for a project to link a specific Git repository for configuration files?
(I have not tested)

[andrei-dascalu]

+1 for this.

I was actually just looking around today a bit dumbfounded that if I need to pick a chart from a Helm repo to deploy it, I can't provide my own versioned values file(s) and instead I need to manually override values in the Application (either UI or in Git).

This is actually pretty bad in that even with sops integration, we should still be able to provide separately versioned files otherwise we need to encrypt by default the entire Application spec (or not) rather than just values that are secrets.

@JulienBreux: no, that one simply lists allowed repositories to be used as sources in Applications. At the moment one Application can come from one repo (which can be Git or Helm)

[awiesner4]

Adding to the requests for this functionality. In my opinion, requiring a separate values.yaml file to have to exist alongside the chart is a Helm anti-pattern.

It would definitely be extremely beneficial to support simply supplying a values path to inject into the application that is separate from the actual Chart location.

That being said, for others, there is a current workaround that, while hacky, does work with minimal extra overhead (though having this workaround should not suggest that the functionality being requested is not needed).

In your values.yaml directory in repo A, per App you want to deploy, create a corresponding Chart.yaml. In the Chart.yaml declare a dependency section that points to the actual remote Helm chart repo. Inside your values.yaml next to the Chart.yaml, just make sure to add a top-level key matching the sub-chart name so it can pick up your parent values.yaml values. Then, in your Application CR for your app in ArgoCD, point that to your values.yaml location.

Here is an example config i'm using successfully for cert-manager:

repoA/charts/cert-manager/Chart.yaml:

apiVersion: v2
name: cert-manager
version: 1.1.0
type: application
dependencies:
  - name: cert-manager
    version: v1.1.0
    repository: "https://charts.jetstack.io"

repoA/charts/cert-manager/values.yaml

cert-manager:
  installCRDs: true
  global:
    imagePullSecrets:
      - name: dockercredentials

repoB/apps/templates/cert-manager.yaml

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: cert-manager
  finalizers:
    - resources-finalizer.argocd.argoproj.io
spec:
  destination:
    server: https://kubernetes.default.svc
    namespace: cert-manager
  project: default
  source:
    path: charts/cert-manager
    helm:
      valueFiles:
        - values.yaml
    repoURL: https://github.com/repoA/helm-values.git
    targetRevision: HEAD
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true

As I said, it's a bit hacky to create an empty parent chart to just point to the chart you want, but it basically results in the desired outcome, with only one extra file next to your values.yaml.

[arramos84]

No idea why this has been debated for so long. It's a no brainer that being able to override a chart's values from a helm repo without having to use a "proxy chart" should be standard. I was really surprised to see this when I started my migration from flux to argo. Put it on pause for now.

[andrei-dascalu]

@awiesner4 hardly a workaround. You need to create a proxy chart. Basically you wrap a chart into another that's in a git repo instead of a helm repo for the benefit of being in VC.

That said, you might want this if the "app chart" brings together several different charts.

I wonder though if it wouldn't work to version the ArgoCD Application. An override values yaml is part of the definition of Helm Applications so that could be versioned.

[awiesner4]

Reiterating that I don't think this should negate the need for being able to support custom values files from private Git repos while using Helm charts from public helm repos... but at a high level, this is one of the least intrusive workarounds I've had to do in a while.

At a minimum, the goal is to be able to store your values.yaml in your own git repo, and point to that. This achieves that.

The additional overhead is just that:

• you have to create the "proxy chart" by just creating the Chart.yaml pointing to the dependent chart
• Make sure your values.yaml has a top level key with the name of that target sub-chart so it picks up your values.

You do not have to store the actual sub-chart in Git. All you need is the Chart.yaml and values.yaml of your 'parent' chart, and the actual chart you want to run is stored in a Helm repo you point to in the dependency section.

So, while it is a 'proxy chart', it's nothing more than really an additional file saying, "go look here for another chart."

Longer term, I'm really hoping this functionality is added. Helm is an extremely popular and easy tool for delivering and managing k8s applications and not supporting custom values.yaml files in a GitOps fashion seems to be an incorrect choice.

[KaiReichart]

I will have a look at solving this, this is a major pain point for us currently too.
Do you guys have any preferences about notation in the template? I was thinking of something like this:

spec:
  source:
    helm:
      extraValueFiles:
        - repo: https://github.com/repoA/helm-values.git
          valueFiles:
             - values1.yaml
             - values2.yaml
        - repo: https://github.com/repoB/helm-values.git
          valueFiles:
             - values1.yaml
             - values2.yaml

[perezjasonr]

I will have a look at solving this, this is a major pain point for us currently too.
Do you guys have any preferences about notation in the template? I was thinking of something like this:

spec:
  source:
    helm:
      extraValueFiles:
        - repo: https://github.com/repoA/helm-values.git
          valueFiles:
             - values1.yaml
             - values2.yaml
        - repo: https://github.com/repoB/helm-values.git
          valueFiles:
             - values1.yaml
             - values2.yaml

that is awesome. And I think the format you presented looks great.

[Cajga]

The "proxy chart" solution does not work if you have your chart in a private helm repo which requires auth. In the final solution we should have the possibility to have both the values.yaml and the chart in two separate (git and helm) private repos.

[rubenssoto]

Hello,

@KaiReichart thank you so much to solve this problem, do you have any idea when this PR will be merged?
Me and my team are testing argocd right now

[KaiReichart]

Unfortunately the argocd team has not yet responded to the PR, so I can't really say when this will make it's way into argocd...

Irrespective of this I can only recommend argocd, it's powering a lot of client applications for us already and there's only more to come ✊

[eytanhanig]

@KaiReichart To help move your PR along I've requested that it be part the agenda for next Wednesday's Argo CD & Rollouts Community Meeting. In preparation for that can you please update/rebase your PR so there are no merge conflicts?

If this is too short notice I can retract my request and bring it up during a future meeting. And if you are able to make the changes it'd be great to have you attend given your expertise. Details for attending it can be found here.

[jessesuen]

Duplicate of #2789

@KaiReichart To help move your PR along I've requested that it be part the agenda for next Wednesday's Argo CD & Rollouts Community Meeting. In preparation for that can you please update/rebase your PR so there are no merge conflicts?

We actually discussed this today's contributors meeting. See #2789 (comment) for the summary. October's CD/Rollouts meeting is being cancelled because many of us are going to be busy with KubeCon tasks.