Hook GitLab Custom Resource to post-install and post-upgrade
This is part of #819 (closed) which aims to install Operator in one step with a single command.
To make sure that Helm can successfully verify and create Custom Resources, they must be associated to post-install
and post-upgrade
hooks. As a result, they can be installed only after CRD is created.
Also, to make sure that further release upgrades won’t fail, use helm.sh/hook-delete-policy: before-hook-creation
(see this for an explanation).
The upstream etcd Operator is the inspiration for our proposal here. In the etcdOperator and helm chart:
- The operator installs the crd into the cluster
- The helm chart optionally creates the resources using hooks
For our own implementation, we don't want the operator to need the elevated permissions needed to install a CRD. (For now we will leave that to tiller), so our proposal looks like:
- Have Helm continue to install/manage our CRD
- Move the GitLab custom resources into helm hooks.
Considerations:
- For now
operator.enabled
should remain defaulted to false -
operator.bootstrap
should default to true, and should install the CRD ifbootstra
p andenabled
are true - The
operator.bootstrap
flag should no longer turn off the the operator deployment, or custom resources - The use of hooks in the custom resource should be conditional based on a flag. By default we will use the hooks, but if users can't use helm hooks, they can turn off
bootstrap
, turn off the use of hooks in the custom resource, install the CRD manually into their cluster, then use the chart without the hooks, but still with the operator.
Edited by DJ Mountney