Problem
The current implementation of FluxHelmRelease Custom Resources uses the following format for providing customizations:
values:
- name: imageTag
value: a00000a
- name: memory
value: 4Gi
This implementation can be simplified.
A/C
The user can add his customizations in the Custom Resource for a chart release in the form:
values:
imageTag: a00000a
memory: 4Gi
I agree that the 2nd option is more user-friendly.
However, it's important to understand that first option is commonly used in Kubernetes, it's often referred to as "keyed list", and I believe it's mostly for patching functionality there is a common method called patchMergeKey and user-facing aspects are documented at the following pages:
Maybe we don't need to support patching, but I'm not sure.
A good point, patching may be needed.
In this case patching the object isn't something that makes sense to support. The expectation is that updates to our CustomResource will be made by Flux, where the old object is simply overwritten.
I don't think there's any compelling reason to use a keyed-list here.
Discussion regarding the pros and cons of different approaches is in the Discussion about the format of the overriding spec.values comment in #982
Addressed by #1035.
Most helpful comment
In this case patching the object isn't something that makes sense to support. The expectation is that updates to our CustomResource will be made by Flux, where the old object is simply overwritten.
I don't think there's any compelling reason to use a keyed-list here.