Add operator without installer and move shared-secrets to operator
Closes https://gitlab.com/charts/gitlab/issues/783
Closes https://gitlab.com/charts/gitlab/issues/758
Closes https://gitlab.com/charts/gitlab/issues/753
Closes !435 (closed)
Closes !503 (closed).
Part of https://gitlab.com/gitlab-org/distribution/gitlab-operator/issues/29
Currently we have an installer job that runs and installs the operator first thing using a pre-install/pre-upgrade hook. This made the operator outside of the controller of helm.
The MR removes the installer and directly installs operator using helm.
Concerns?
. How do we make the operator release namespaced (namespacing here means isolation not kubernetes namespace) so that we can have an operator deployed for every release?
This is handled by using a custom subgroup name for our operator apigroup guaranteeing an api group for every release thus the kind can still be GitLab but since the api group is different no collisions shall happen. The operator reads the subgroup name (which is optional) using an environment variable API_SUBGROUP.
. How do we make sure that the crd is installed first before attempting to create an instance of GitLab ?
This is handled by helms crd-install hooks. We can't use any other type of hooks because helm will try to validate the GitLab instance manifest before the CRD is installed and thus throw an error. This custom hooks specifically delays the validation until we have the crd in place. This hook was introduced in helm 2.10.0 which means in order to use the changes in this MR users will be required to use a at least this version of helm.