search

vmware-tanzu / helm-charts

Contains Helm charts for Kubernetes related open source tools
https://vmware-tanzu.github.io/helm-charts/
Apache License 2.0
241 stars 357 forks source link

Separate CRD into a new chart #421

Open jenting opened 1 year ago

jenting commented 1 year ago

Describe the problem/challenge you have

According to the helm chart best practice, separating CRD into a dedicated chart is a good way to manage the lifecycle of the CRD.

We have much community feedback on the existing CRD upgrade has some limitations. Currently, the CRD upgrade is in the last step of the helm upgrade, by using an upgrading job to update the cluster CRDs which is incorrect because the CRD should be installed first and then upgrading the CRs.

Here are the issues we should consider separating CRD into a new chart.

Describe the solution you'd like

Separate velero CRD into a new chart.

However, this would breaking the backward-compatible because once we separate two helm charts during helm upgrade, the steps are:

Therefore,

  1. We need to mention that the user should uninstall the old velero helm chart and reinstall the new velero helm chart in the doc
  2. It's a breaking change, so bumping the chart major version is required
qiuming-best commented 1 year ago

@jenting In the next release, we will develop one velero upgrade command, here is the design pr, for the issues listed above, if some of them could be solved by enhancing the velero upgrade command, please comment on it.

For the CRDs parts: every release it's needs to sync from upstream, basically, it's not configurable (its configuration is not from values.yaml), so what about we don't need crds in the helm chart. our velero could enhance the velero install or velero upgrade command to apply CRDs and helm chart could use one or two jobs to install or upgrade CRDs by using velero cmd ?

for the issues listed above, could we improve the velero install or upgrade to solve them?

desaintmartin commented 1 year ago

I second this new chart request, since a lot of people un-couple CRDs installation from actual Helm Release deployment, allowing much more flexibility / maintainability / infrastructure-as-code.

daodennis-ri commented 10 months ago

I'm for this idea but I am wondering, if the CRDs are in a separate chart what are the mechanics behind when they need to be updated? Is the idea they are put into the templates/ directory and just treated like any other Kubernetes object or are they still in the crds/ folder?

jenting commented 10 months ago

@daodennis-ri Within the templates/ directory.

daodennis-ri commented 10 months ago

@jenting thanks for getting back to me! If the CRDs are in the templates/ folder, aren't the CRDs removed if we uninstall the release with helm (i.e. helm uninstall), or is this functionality just not triggered for Velero CRDs (and how am I supposed to know/check that).

jenting commented 10 months ago

Yes, the idea is to separate two charts, let's say velero-crd and velero. In general, for every new release, we run helm upgrade velero-crd first and then velero. We can't control users or operators to force uninstall velero-crd, the same as to the velero helm chart.

desaintmartin commented 10 months ago

Note that it does not actually require remove the CRDs from the main chart, so that the "old" method still works.

tanguynicolas commented 1 month ago

What's the cleanest workaroud in the meantime?

I thought of installing the chart with only:

backupsEnabled: false
snapshotsEnabled: false
schedules: {}

Then change to my full custom configuration. But it's not great.

Any recommendations?