Split the operator bootstrap out of the chart
Summary
In order to use the GitLab operator, you currently need to first install the chart with boostrap set to true, then run it again with bootstrap set to false. This is because we need to install the custom resource CRD before we can then use the resource. We implemented the bootstrap in this way as a stepping point to eventually getting the requirements down to a single command: #819 (closed)
This has proven to be extremely difficult to do cleanly. And while helm 2 has a crd-install hook, using it does not support updating the crds. After many months of looking at solutions for this, and keeping our eye on what others are doing. We have determined that:
- Using a second command to install the CRD is both accepted and expected in the ecosystem
- The account that can install the CRD can often be different than those allowed to install the app. Further making two commands make sense.
- New systems that support CRDs, like RedHat's Operator Lifecycle Manager, are installing the crd first, then installing your app. We also expect this two-step approach to be used by various marketplace wrappers.
- Helm 3 is expected to improve CRD creation, but still through a two-step install process with differing RBAC.
As a result, we have decided to focus on improving this two step install of the operator for now, rather than trying to get it all working in one helm install command.
Proposal
Get rid of the bootstrap flag in our chart, as this not a pattern seen anywhere else. Instead we should distribute the CRD separate from the GitLab chart, and include install steps in our operator docs, and in the chart notes.
For this we can first look doing this a single kubectl
command line to run before the helm install.
We have further followup ideas to better manage this CRD through the use of an operator, but we will gather those in separate issues.