Provide ability to deploy CRDs independently of application

[tylerauerbeck]

We have a need to be able to deploy the CRDs for the operator independently of the application itself (i.e. in some cases, we may just want to install CRDs, in other cases we may just want to deploy the operator without the CRDs, and in other cases we may want it all).

This has initially arisen because of the size of the CRDS themselves when attempting to install the CNPG operator chart inside of ArgoCD. As has been known to happen with other applications being kubectl applyd , the only option is to use the Replace=true option which resolves the problem. Currently (by having everything installed together) this causes everything to be replaced. However, if we were able to provide separate values files for this where we could control the deployment of the various sets of components independently, we wouldn't need to force a Replace on running components each time we synced.

[fouadsemaan]

Chart: cloudnative-pg Version: 0.21.2

Recreate also has to be called to avoid validation issues when used in conjunction with "validate=false".

This however is also not a long term solution as my fear is the recreation of the CRDs may in fact delete the CR instances.

Besides the server-side apply to solve the long CRDs, can we fix the validation issue? It also creates another issue whereby ArgoCD can't calculate the diff between the desired manifest and actual manifest.

Server side apply will suffice if validation is fixed.

[chgl]

Would allowing to set annotations on the CRDs be another option (https://github.com/prometheus-community/helm-charts/issues/3548#issuecomment-1621222012) ?

So something like:

crds:
  annotations:
    argocd.argoproj.io/sync-options: ServerSideApply=true

adds the annotation to https://github.com/cloudnative-pg/charts/blob/main/charts/cloudnative-pg/templates/crds/crds.yaml#L5.

[Stevenpc3]

We also need to be able to apply the CRD only once. We have a case where we need to install the CRD cluster wide on cluster creation. Then we will deploy the operator to limited namespaces via the charts and currently we can set a flag to not install crd, but the ability to install the CRD the first time remains an manual step, unless the operator chart can be in a CRD only mode like "--set operator.enabled=false" or something.

Honestly, the best bet would be to make the CRD it's own chart. Then make that CRD chart a dependency of the operator chart if crd.enabled=true.

This will allow the option to only install the CRD chart which just applies the crds.yaml and still can easily make use of the existing crd.create flag in the operator chart.

crds:
  # -- Specifies whether the CRDs should be created when installing the chart.
  create: true

[Stevenpc3]

I likely will make a PR.

The best way to do this is how Elasitcsearch does their ECK operator.

They have the CRDs as a separate chart https://github.com/elastic/cloud-on-k8s/tree/main/deploy/eck-operator/charts/eck-operator-crds then the operator depends on this. https://github.com/elastic/cloud-on-k8s/blob/main/deploy/eck-operator/Chart.yaml#L34

This allows you to deploy normally or optionally deploy the CRDs alone separately.

[jmcorne]

I am facing the same issue (Pooler CRD is too huge and does not fit last-sync annotations) with ArgoCD 2.4, which has no server-side sync option.

Is it possible to add an option to CNPG plugin for kubectl, to generate the crd only? If so this will allow us to create a job in presync hook to manage CRD lifecycle?

And the command may look like kubectl-cnpg install generate --version 1.22.1 --crds-only --dry-run -o yaml | kubectl apply -f -