CRD handling for flux2 chart

[maximveksler]

Is your feature request related to a problem ?

When deploying flux2 coupled with followup manifest deployment fails.

hashicorp/terraform-provider-kubernetes#1367 (comment)

Describe the solution you'd like.

Implement CRD handling with helm3 approach https://helm.sh/docs/chart_best_practices/custom_resource_definitions/

Describe alternatives you've considered.

Use kubectl provider, however this approach is edgy as well.

Additional context.

No response

[stefanprodan]

Helm can't upgrade CRDs if we place them in the crds dir, which means Flux will fail after an upgrade as every release comes with CRD changes.

[maximveksler]

@stefanprodan have you considered using velero's approach of hooks for the upgrade part?

https://github.com/vmware-tanzu/helm-charts/tree/main/charts/velero/templates/upgrade-crds

[stefanprodan]

I would not consider running kubectl apply in a Helm hook, that's a horrible hack, the CRDs should be included in Helm storage not YOLO applied via a Job.

If you are looking for a way to deploy Flux with Terraform, we offer a Flux provider https://github.com/fluxcd/terraform-provider-flux

[joaocc]

Hi. In our case, we are deploying flux as part of vcluster deployment (init-time manifests) so we don't have an easy access to the vcluster without a lot of plumbing.
In this case we deploy flux as helm to be run as soon as vcluster comes up, and then we deploy the different manifests required for bootstrapping from git and whatnot.
Being able to trust that the helm chart can update itself would be great.
We have seen some packages get the CRDs into a pre-chart and then the product itself on a 2nd chart. Would this be an option that you would see favourably?
Thx