feat(tiller): support CRD installation#3982
Conversation
|
yay, long awaited feature 😀 |
ed70473 to
8de8ab9
Compare
|
Okay, here's how this works First, if you are just creating a CRD with no instances of that CRD, you do nothing (just as always). This is designed to allow for a CRD and instances of the CRD to be installed in the same chart. It is also designed to be maximally backward compatible, though I did have to eliminate one set of validations in order to do this. To add a CRD to a chart, create a CRD template and set an annotation on the template: apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
name: crontabs.stable.example.com
# THE IMPORTANT PART!!!
annotations:
"helm.sh/hook": crd-install
spec:
group: stable.example.com
version: v1
scope: Namespaced
names:
plural: crontabs
singular: crontab
kind: CronTab
shortNames:
- ctYou can also create a template that references that CRD: apiVersion: stable.example.com/v1
kind: CronTab
metadata:
name: {{ .Release.Name }}-instNow, when you run
If |
This adds support for installing CRDs well before any other resource kinds are installed. This PR introduces a new hook, `crd-install`, that fires before manifests are even validated. It is used to install a CRD before any other part of a chart is installed. Currently, this hook is _only implemented for install_. That means we currently cannot add new CRDs during `helm upgrade`, nor can they be rolled back. This is the safest configuration, as the update/rollback cycle gets very challenging when CRDs are added and removed.
8de8ab9 to
f2899d3
Compare
| return e | ||
| } | ||
|
|
||
| if entry.Version != "" && !file.apis.Has(entry.Version) { |
There was a problem hiding this comment.
To be really clear: I am removing this set of checks. It appears to duplicate the check in validateManifest, and it fires well before we have a chance to install the CRD.
|
@technosophos , what should I do if I want to support last 2-3 version of helm with the same chart? Is there a better option that use if-else with |
|
What helm version is this feature going to be in? |
|
2.10 |
|
What is the difference of this fix with #3019 ? @technosophos |
|
/cc @morvencao |
|
#3019 is for custom resources (CRs) to the sorting list, whereas this PR adds support for custom resource definitions (CRDs). Prior to this hook being available, charts could not install CRs and CRDs because the manifests would be validated all in one step prior to the CRDs being installed. The docs that were added to this PR goes into a little more detail on this new hook, which can be found here: https://docs.helm.sh/developing_charts/#defining-a-crd-with-the-crd-install-hook Does that help explain this fix, or is there something else we should document? |
|
@bacongobbler I think #3019 is also for CRD but not CR, #3019 is trying to enable all of the CRDs should be created first before other resources take reference of this CRD. Am I missing anything? |
This adds support for installing CRDs well before any other resource kinds are installed. This PR introduces a new hook, `crd-install`, that fires before manifests are even validated. It is used to install a CRD before any other part of a chart is installed. Currently, this hook is _only implemented for install_. That means we currently cannot add new CRDs during `helm upgrade`, nor can they be rolled back. This is the safest configuration, as the update/rollback cycle gets very challenging when CRDs are added and removed. Signed-off-by: Sebastien Plisson <sebastien.plisson@gmail.com>
This adds support for installing CRDs well before any other resource kinds are installed. This PR introduces a new hook, `crd-install`, that fires before manifests are even validated. It is used to install a CRD before any other part of a chart is installed. Currently, this hook is _only implemented for install_. That means we currently cannot add new CRDs during `helm upgrade`, nor can they be rolled back. This is the safest configuration, as the update/rollback cycle gets very challenging when CRDs are added and removed. Signed-off-by: Sebastien Plisson <sebastien.plisson@gmail.com>
This adds support for installing CRDs well before any other resource kinds are installed. This PR introduces a new hook, `crd-install`, that fires before manifests are even validated. It is used to install a CRD before any other part of a chart is installed. Currently, this hook is _only implemented for install_. That means we currently cannot add new CRDs during `helm upgrade`, nor can they be rolled back. This is the safest configuration, as the update/rollback cycle gets very challenging when CRDs are added and removed.
This adds support for installing CRDs well before any other resource kinds are installed. This PR introduces a new hook, `crd-install`, that fires before manifests are even validated. It is used to install a CRD before any other part of a chart is installed. Currently, this hook is _only implemented for install_. That means we currently cannot add new CRDs during `helm upgrade`, nor can they be rolled back. This is the safest configuration, as the update/rollback cycle gets very challenging when CRDs are added and removed.
This adds support for installing CRDs well before any other resource kinds are installed. This PR introduces a new hook, `crd-install`, that fires before manifests are even validated. It is used to install a CRD before any other part of a chart is installed. Currently, this hook is _only implemented for install_. That means we currently cannot add new CRDs during `helm upgrade`, nor can they be rolled back. This is the safest configuration, as the update/rollback cycle gets very challenging when CRDs are added and removed.
This adds support for installing CRDs well before any other resource
kinds are installed.
This PR introduces a new hook,
crd-install, that fires beforemanifests are even validated. It is used to install a CRD before any
other part of a chart is installed.
Currently, this hook is only implemented for install. That means we
currently cannot add new CRDs during
helm upgrade, nor can theybe rolled back. This is the safest configuration, as the update/rollback
cycle gets very challenging when CRDs are added and removed.