Research: Potential of using Helm v3 SDK as a template base

Summary

I'd like to propose that we research consuming the Helm v3 Go SDK within this Operator, using the Helm chart work as a method by which we can generate known-functional output. That output, similar to helm template but in data model form, could be consumed and transformed to meet the needs of this Operator in any environment, without adding barrier to entry. This reduces the internal complexity of the object management code within this operator, and allows more flexibility to rolling feature additions and changes. We'd have the possibility of decoupling the deployed GitLab suite's version of the Operator's version, which brings us the benefit of faster and more focused iteration on the operator-specific patterns.

This level of integration was not a feasible item prior to the release and revisions of Helm v3.x, thus it may seem counter to my previous epic on gitlab-org/charts/gitlab regarding a multi-component operator, which actually resulted in two operators.

This is not "make this a Helm Operator". This is use Helm as the tool it is, integrated as a part of the stack.

Value

By having this operator consume gitlab/gitlab, we take the direct complexity of contributing through multiple paths out of play. The operator becomes a mutating wrapper with support for OpenShift, with added Day 2+ knowledge, effectively replacing the existing operator within gitlab/gitlab itself.

Example case

One such example change is alterations Gitaly's config.toml (as seen here). This relatively "minor" change, actually breaks compatibility between 12.10 and 13.0, such that the chart deployed by gitlab/gitlab v3.3.0 is unable to consume containers at application version 13.0. gitlab/gitlab v4.0.0 is required for 13.0 to work.