Skip to content

A way to keep values.yaml DRY #495

Description

@ilya-lesikov

Before proceeding

  • I didn't find a similar issue

Problem

values.yaml files can grow complex, especially when using generic charts like this. Imagine you plug this chart 10 times under different chart aliases to deploy 10 applications in the same release. Then there will be a lot of configuration duplicated in values.yaml between these apps.

To keep values.yaml DRY, YAML only has aliases and anchors, but they have way too many limitations, like no deep merge for maps, no cross-file aliases, etc.

Solution (if you have one)

We could allow Go templating in values.yaml. I'm not for it:

  1. Too complex.
  2. Not valid YAML anymore.
  3. I don't want to force users to use Go templates, when they use (not implemented yet) alternative to Go templates for manifests.

Long time ago as a werf user I did _include key support in Helm templates. This worked surprisingly well.

I'm thinking on implementing something like __merge natively in Nelm. This is very simple, but flexible approach, and it will still be valid YAML.

It might look like this. Given:

defaults:
  base:
    ingress: true
    replicas: 1

  backend:
    ingress: false
    resources:
      limits:
        memory: 256Mi
      requests:
        memory: 128Mi

backend1:
  __merge: .defaults.base, .defaults.backend
  replicas: 3

... results in:

backend1:
  ingress: false
  replicas: 3
    resources:
      limits:
        memory: 256Mi
      requests:
        memory: 128Mi

It can have everything that YAML aliases don't have: deep map merge, etc.

All merges will be processed after Helm compiles the one merged values tree. Validation with values.schema.json might be affected, but we might just forcefully do additionalProperties: true everywhere.

Additional information

No response

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions