✨ (helm/v2-alpha) - dynamic value templating

[asergeant01]

Summary

Enhances the Helm v2-alpha plugin to automatically detect custom values added to values.yaml and inject corresponding Helm template syntax when regenerating charts with kubebuilder edit --plugins=helm/v2-alpha.

Enhancement #5485

[k8s-ci-robot]

Hi @asergeant01. Thanks for your PR.

I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: asergeant01
Once this PR has been reviewed and has the lgtm label, please assign varshaprasad96 for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[camilamacedo86]

Thanks so much for looking into this 🙌

One important point: values should not be overridden unless we explicitly use --force, so users can keep their customizations — and it sounds like that expectation is still respected here (which is great).

Just to make sure I understand, the workflow with this proposal would be:

1. Run kubebuilder edit --plugins=helm/v2-alpha to generate the chart
2. Edit values.yaml to expose/customize something
3. Re-run kubebuilder edit --plugins=helm/v2-alpha to update the chart according to what’s in values.yaml

That’s an interesting idea. I’ll need some time to play around with it, but a couple potential drawbacks come to mind:

Concerns

1. Expose everything?
   This creates a big surface area. It’s unclear whether we want the default experience to be “highly configurable” or more “opinionated/curated”.

2. Supportability
   Without a curated list of “first-class” options, documentation and support get harder (and it becomes harder to test the chart against a well-defined set of supported knobs).

3. Fragile injection
   The injection appears to rely on string/regex manipulation of YAML. If the manager manifest shape changes, we might inject in the wrong place or miss entirely. There aren’t strong structural guarantees.

4. Special characters
   Keys like custom.io/foo get escaped in the values path (custom_io_foo). That can be surprising and may not match user expectations.

5. Labels/annotations scope
   It should be very clear whether these values are applied only to the manager (Deployment/pod template) vs globally across resources. Applying them globally by default could be surprising.

Overall, I’m not sure yet this is the right direction as-is — we may want to go step-by-step and only expose what clearly makes sense to be configurable, maintain a well-defined/accurate list of supported keys, and aim for good practices + maintainability.

I will need some time to think about and play around.

[camilamacedo86]

Hi @asergeant01,

Right now we expose the values that already make sense for end users.

I think the proposal is an interesting idea, but it’s brittle and difficult to support long-term. It could also encourage exposing options that don’t make sense for chart consumers. I’m not sure that’s the right direction.

Instead, I’d prefer we discuss each additional item we want to expose on a case-by-case basis. Project authors should be able to customize the config, and that should flow into the chart—but the chart values should remain focused on knobs that are reasonable for end consumers to change.

For clarity, we already expose the install-time customization values under manager (extracted from Kustomize when present and surfaced in values.yaml, overridable via --set or a values file), plus these chart-level manager-related toggles:

• Manager deployment (manager.*): replicas, image repository/tag/pullPolicy, args, env, imagePullSecrets, podSecurityContext, securityContext, resources, affinity, nodeSelector, tolerations
• Chart-level (manager-related): metrics.enable, metrics.port, webhook.enable, webhook.port

So beyond #5496, what else do we think we should expose? If there are specific additional values you’d like to see, could we track them in a separate issue (or issues) so we can evaluate them individually?

Thanks,
Camila

[asergeant01]

@camilamacedo86 Yes, that's no problem. I actually prefer this more defined approach. it was purely from your comment...

I think we might be able to:

Check if in the YAML we have extra/additional values
If so, then we add to the values as requested

that I thought you wanted something more dynamic.

I think then I can close this PR and open issues for the remaining values I think should be configurable.