Open astefanutti opened 7 months ago
Is this something you or your team is interested in taking?
That won't be a high priority for us as we're not using Helm charts.
I've created the issue more as a follow up from https://github.com/kubernetes-sigs/kueue/pull/1695#discussion_r1489203905 than something we would really need 🙂.
@alculquicondor @astefanutti If this issue is not a high priority in both teams, should we mark this as a good-first-issue?
I'm not sure it's a good "first" issue, but we can give it
/help
@alculquicondor: This request has been marked as needing help from a contributor.
Please ensure that the issue body includes answers to the following questions:
For more details on the requirements of such an issue, please see here and ensure that they are met.
If this request no longer meets these requirements, the label can be removed
by commenting with the /remove-help
command.
/assign I'll take a look into this.
I'm unable to give time to this right now. Unassigning myself so someone else can give it a go.
What would you like to be added:
The Helm charts are currently synchronised from the Kustomize manifests, that are the source of truth for deploying Kueue, with the
hack/update-helm.sh
script, that performs a series of ad-hoc file manipulations usingyq
andsed
commands.It would be great to consider a more robust approach to generate the Helm charts from the Kustomize manifests. Part of the solution could be to move to a strongly typed approach, or (not necessarily mutually exclusive) add some tests that'd guarantee the generated Helm charts are valid.
Why is this needed:
1695 has added an extra level of complexity to that script, reaching a point where it may become difficult to maintain it, and guarantee non-regression, as discussed in https://github.com/kubernetes-sigs/kueue/pull/1695#discussion_r1489203905.
This enhancement requires the following artifacts:
The artifacts should be linked in subsequent comments.