Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Values precedence in Helm is an incompatibility mess! #12677

Open
hedayat opened this issue Jan 2, 2024 · 6 comments
Open

Values precedence in Helm is an incompatibility mess! #12677

hedayat opened this issue Jan 2, 2024 · 6 comments

Comments

@hedayat
Copy link

hedayat commented Jan 2, 2024

There was a behavior in Helm versions up until 3.8.2, which broke in 3.8.2 as reported in #10998 and #10899.

This was an incompatible change, appeared in a minor version!

Finally, it was fixed in #11162

However, then #12460 was reported as an incompatibility and the behavior reverted back to that of 3.8.2-3.12.

And now #12599 and #12511 are also open.

It is really frustrating, please decide on the final behavior for once and fix it. Note that the old behavior makes things possible that is not possible with the new one. I personally prefer the old one (that of the versions prior to 3.8.2), as it allows you to override some values using a tag to import and override some other values.

@gjenkins8
Copy link
Contributor

See the notes on:
#12162

(and which was slightly patched with #12480 )

#12162 fixed many bugs. Unfortunately fixing these ultimate was going to change Helm behavior, especially for users who had "discovered" how Helm worked in certain scenarios. And thus had become reliant on the buggy implantation.

#12162 + #12480 are intended be the final implementation. But ultimately (IMHO) that given a lot of this behavior has been implemented without a tight specification, it is subjective as to what the "correct" behavior actually should be. And there still might be further bugs out there.

@hedayat
Copy link
Author

hedayat commented Jan 5, 2024

First, as far as I can see, imported values does NOT override other sub-chart values. Actually, it seems that imported values doesn't override anything.

Second, the 'Using the child-parent format' section in Helm docs (https://helm.sh/docs/topics/charts/) explicitly says that imported values override parent values, as it was true before Helm 3.8.2. So, if there isn't any spec, there is at least documentation (and also old behavior). The example in docs:

Parent chart:

# parent's Chart.yaml file

dependencies:
  - name: subchart1
    repository: http://localhost:10191
    version: 0.1.0
    ...
    import-values:
      - child: default.data
        parent: myimports
# parent's values.yaml file

myimports:
  myint: 0
  mybool: false
  mystring: "helm rocks!"

# subchart1's values.yaml file

default:
  data:
    myint: 999
    mybool: true

The parent chart's resulting values would be:

# parent's final values

myimports:
  myint: 999
  mybool: true
  mystring: "helm rocks!"

As can be seen, it is expected that imported values override parent ones (e.g. myint became 999).

@hedayat
Copy link
Author

hedayat commented Jan 5, 2024

3.8.2 and later (except 3.13.0) are buggy in this regard, and now Helm prefers to be compatible with its buggy version rather than older versions & its own docs. And you lost a feature: you can't have a batch of overriding values to be enabled using just a tag.

@hedayat
Copy link
Author

hedayat commented Jan 5, 2024

We relied on this behaviour since Helm 2 times, and it worked fine & according to the docs until 3.8.1. And, there is NO solution for it with the new behaviour.

Anybody relying on the behaviour of later versions with regard to imported values is relying on a buggy behaviour. Why compatibility with few buggy versions is more important than a behaviour which is both documented and exists from the early days?!

I really hope it'll revert back to the old behaviour. The new one makes imported values almost useless, as they cannot override anything even other subcharts default values.

Copy link

github-actions bot commented Apr 5, 2024

This issue has been marked as stale because it has been open for 90 days with no activity. This thread will be automatically closed in 30 days if no further activity occurs.

@github-actions github-actions bot added the Stale label Apr 5, 2024
@joaocc
Copy link

joaocc commented Apr 5, 2024

/nostale

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

No branches or pull requests

3 participants