feat(argo-workflows): Add support for full CRDs

[Joibel]

This change adds the capability to install full CRDs (with complete OpenAPI schemas) instead of the minified ones. This is controlled by a new configuration option crds.full which defaults to false (minified CRDs).

Changes:

• Add new crds.full configuration option in values.yaml (defaults to false)
• Create templates/crds-full/ directory with full CRDs from upstream v3.7.3
• Move existing minified CRDs to templates/crds-minified/
• Add conditional logic to install either full or minified CRDs based on config
• Update README.md with documentation about the new option
• Update CONTRIBUTING.md with namespace creation
• Update default namespace documentation for argo-workflows
• Use /usr/bin/env bash for better compatibility in scripts

Possibly in 4.0 we (the workflows team) will suggest switching this to default true.

If you don't like my "minor fixes along the way" in this PR, I'm happy to split it.

3 of the 8 CRDs are already "full" so we have duplicates of them in the current format. We could put them in a common place if that is preferred. I'm new to this repo and your preferred practices.

Checklist:

• I have bumped the chart version according to versioning
• I have updated the documentation according to documentation
• I have updated the chart changelog with all the changes that come with this pull request according to changelog.
• Any new values are backwards compatible and/or have sensible default.
• I have signed off all my commits as required by DCO.
• I have created a separate pull request for each chart according to pull requests
• My build is green (troubleshooting builds).

[jmeridth]

Thank you for the "housekeeping" items also. Excellent updates on the README.

[vladlosev]

I would like to sound a note of caution here. Full Argo Workflows CRDs are very large and will slow down the processing substantially. It my work we use A GitOps automated sync deployments, and when we tried to use full CRDs, the process slowed down enough to start timing out. This change does not default to full CRDs, but there are still costs being added

• The download size increases significantly. That might affect both bandwidth consumed and time spent on downloading the charts. Hopefully, most CD systems cache these downloads, though.
• These CRDs are implemented as direct Go templates. This means Helm will have to read and parse process the entire CRD template just in order to generate an empty output from it. It's quite a bit of CPU and memory consumption. If one is running their CD solution in a container with limited memory requirements, this change is likely to exceed them and cause OOMs.

The former problem is annoying, but the latter can be a real breaking change for some. There are ways to rectify these issues. For example, the actual CRDs can be kept in flat files, and the CRD template could be a short stub loading them via Helm's File feature, like this:

{{- if .Values.crds.install }}
{{- $pattern := ternary "files/crds/full/*.yaml" "files/crds/minimal/*.yaml" .Values.crds.full }}
{{- range $path, $_ :=  .Files.Glob  $pattern }}
---
{{ $.Files.Get $path }}
{{- end }}
{{- end }}

This approach avoids the overhead of processing large CRD templates when they are not required. Incidentally, it will also let us copy the CRDs files verbatim from the Argo Workflows project, reducing maintenance burden of turning them into templates.

[Joibel]

@vladlosev, lets hold on merging this, and I'll do that (next week now), it's a very neat pattern.

Thank you.

Back in draft

[Joibel]

It doesn't seem it's possible to modify files from Files.Get, which makes adding the annotations impossible - is there a way around that? I've pushed up a new version with something like the modifications suggested, but it's broken CI and it's broken crds.keep and crds.annotations.

I don't have a way to fix this, but I'm no helm expert - asking for assistance with that.

[vladlosev]

You may be able do something like this here:

{{ regexReplaceAllLiteral "\n  annotations:\n" ($.Files.Get $path) "\n    annotations:\n  helm.sh/resource-policy: keep\n" }}

May even abstract it into a function call, e.g.,

{{ include "argo-workflows.insertResourcePolicyAnnotation" (dict "input" ($.Files.Get $path) "value" "keep" }

The function may look like this:

{{- define "argo-workflows.insertResourcePolicyAnnotation" -}}
{{ regexReplaceAllLiteral "\n  annotations:\n" .input (format "\n    annotations:\n  helm.sh/resource-policy: %s\n" .value) }}
{{- end -}}

[Joibel]

I have tried to implement this

[Joibel]

It's a neat trick, I hadn't realised this was possible - thank you.

[Joibel]

@vladlosev I have rebased, but the actual changes requested are in d34f459

[vladlosev]

The new full CRDs seem to lack the metadata.name fields.

[vladlosev]

Other issues have been fixed, but the new full CRDs still lack the metadata.name fields. They are not valid without it.

[Joibel]

Other issues have been fixed, but the new full CRDs still lack the metadata.name fields. They are not valid without it.

Apologies, missed this. Done now

[Joibel]

Thank you all

[Joibel]

I successfully deployed this via ArgoCD with an application with SSA enabled. application-controller needed more memory limit to work, but it did the update. (Kube-prom-stack would deploy with the old memory limit, so this was a bit surprising)