-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Separate CRD manifest #2726
Comments
Would you prefer to have them as a YAML file in that case? |
Yes, that would be ideal |
Any thoughts on this @zroubalik? |
Fine for me, the CRDs are already part of the big The release is being done here: keda/.github/workflows/release-build.yml Lines 57 to 60 in 8c85751
@ishioni are you willing to contribute this? |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions. |
We have another use case. We'd like conditional deployment of the KEDA resources from a template (e.g. templates/keda.yaml) but Helm 3.x must process the CRDs in advance. We don't need conditional deployment of the CRDs. |
Proposal
I would like a separate CRD-only yaml to deploy CRDs tak keda uses
Use-Case
I manage my cluster with flux, using their helmrelease CRDs and kustomize. This works fine but on the condition that CRDs are deployed on a separate step before the actual helm release. This is to combat the fact that helm releases in a kustomization step are run in parallel, and if any of them include keda resources, they will obviously fail until keda itself is installed.
Installing only the CRDs in a separate step neatly fixes this. Most projects that use CRDs that I've encountered (cert-manager, tigera) offer separate CRD yamls knowing that helm-managed CRDs are iffy
Anything else?
No response
The text was updated successfully, but these errors were encountered: