Giuseppe Tinti Tomio

In https://github.com/kubernetes-sigs/jobset/pull/824#issuecomment-2813290480, @ahg-g proposed getting rid of Kustomize and using Helm as the source of truth for generating the release manifest. I think this solution is simpler and better than...

> Do we really need to support kustomize if we support helm? AFAIK we only use Kustomize to generate the release manifest. If we can generate the release manifest with...

> We might still have users who rely on kustomize in their production setups. Can you be more specific? : ) The official distributions "helm package" (i.e., `helm install jobset...

> In that case, do you suggest that we rely on Helm to install the latest development version as well? That is one option. Another option is force all merged...

# Summary I compared the release manifest built with Kustomize to one built with `helm template`. I did so to understand what would have to be done to deprecate Kustomize...

@kannon92 @andreyvelich @ahg-g @ChenYi015 let me know what you think of the [analysis](https://github.com/kubernetes-sigs/jobset/issues/820#issuecomment-3499583790). In order to deprecate Kustomize, the release manifest built with `helm template` should be as similar to...

> For the conversion webhook patch, we should add it to CRDs since we enable webhook by default. I think this patch to CRD is for a conversion webhook which...

> Maybe you can open up a PR where you use the manifests in https://github.com/kubernetes-sigs/jobset/issues/820#issuecomment-3499583790 in our CI. > > It would be neat to see if we can generate...

#1084 can be solved by syncing helm and kustomize. To not block #1084 while we decide the best way to automatically sync helm and kustomize, we can make a PR...

I wonder if it makes more sense to support a counter per `replicatedJob` instead of per `failureActionRule`. Would that be enough for your use case?