Reduce the install steps for the operator to a single command
Summary
In https://gitlab.com/charts/gitlab/merge_requests/517 we are going to introduce a two-step installation for the operator. As a followup, we want to explore reducing this back down to a single step.
There was some discussion starting in https://gitlab.com/charts/gitlab/merge_requests/517#note_107521168 about how we might do this:
DJ: Where the next step would be to move just the
kind: GitLab
object into a job running kubeclt apply. Essentially taking it out of validation. Allowing us to be back at a single install command. (This would result in the GitLab object sticking around after delete, but that is the same with issuers at the moment, and we can always looking adding a delete hook to clean up in the future.)
Jason: then what you're suggesting is that we have the
kind: GitLab
actually be created via a Job like certmanager-issuer, but contained within theoperator
chart, correct? Are there any race conditions that would force us to make use of ahelm.sh/hook: pre-*
? Will this further complicate the RBAC needs at all?
Ahmad: I think this proposal goes against what we are trying to do right now. Right now we are trying to make the operator managed by helm. Putting them in a job will defeat the purpose and when we delete the release they won't be cleaned up. Basically it is the same state we were at when we had the installer in place. Can you elaborate on what you are proposing ?
DJ: The only new thing that won't be cleaned up, is the GitLab object. And it doesn't conflict with new installs thanks to using kubectl apply in the job.
While it does leave an additional cruft item. It's better than our prehooks because it doesn't leave rbac config sitting around after delete, or any conflicts. It happens in the normal flows so it doesn't leave your release broken. And it is similar to what we already do for issuer.
It's also not the only cruft we have to deal with. Cert-manager itself leaves its certificates around after delete, and our own operator leaves the shared-secrets. And our existing chart leaves the cert-manager issuer object.
We can consider looking at adding a
post-delete
hook to remove some of these if we want.
Ahmad: Yeah that would work
The only concern I have with that is that we will be relying more on tiller