[go: up one dir, main page]

Skip to content

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:

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 if bootstrap and enabled 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