As a developer\
I want to install charts without Crossplane's provider-helm\
So that I can reduce complexity and external dependency
Context
In #27 we introduced deployments with Helm by outsourcing the Helm installation process to an external operator, provider-helm. The way this operator works is that it wants a cluster-scoped resource Release that describes the Helm release and their values. In addition, it requires a cluster-scoped resource called ProviderConfig, in which the target cluster is specified ("same cluster").
We should investigate and ask ourselves:
Is relying on a 3rd party Helm operator as a dependency ok?
Is another operator (and their resources) worth the added complexity it brings?
Would maintaining our own Helm installation method result in more code than there is to maintain/control the Release CRD?
When looking at the code required to deploy Helm releases, one might think it's quite a bit to integrate provider-helm's code base into this project using Helm's Go library.
However, I believe that integrating the Helm binary and executing it might reduce a lot of boilerplate code (e.g. the chart pulling code). We might loose a few things that provider-helm can do, but it's likely that we don't need the advanced features.
Advantages:
Get rid of a Crossplane dependency
Reduced code to maintain and sync Release code
Reduced operational knowledge required for service engineers in day 2 operations
Packaging helm in the image leaves all helm logic in an external binary
The feedback of failed or successful installations/upgraded is easier to integrate into the instance spec or the operator.
Helm plugins can be used to get more functionality
Disadvantages:
Added code to invoke helm
The operator container/image may need some extra configuration to make helm work, e.g. caching storage volume (e.g. emptyDir) for pulling external charts in various versions.
Summary
As a developer\ I want to install charts without Crossplane's provider-helm\ So that I can reduce complexity and external dependency
Context
In #27 we introduced deployments with Helm by outsourcing the Helm installation process to an external operator, provider-helm. The way this operator works is that it wants a cluster-scoped resource
Releasethat describes the Helm release and their values. In addition, it requires a cluster-scoped resource calledProviderConfig, in which the target cluster is specified ("same cluster").We should investigate and ask ourselves:
ReleaseCRD?When looking at the code of the most essential business logic, we see that a lot of code is lifecycle management required by Crossplane: https://github.com/crossplane-contrib/provider-helm/blob/176aa6812860e95712ea7aecd541a564bc839b14/pkg/controller/release/release.go
There is also additional logic for pulling charts: https://github.com/crossplane-contrib/provider-helm/blob/176aa6812860e95712ea7aecd541a564bc839b14/pkg/clients/helm/client.go
When looking at the code required to deploy Helm releases, one might think it's quite a bit to integrate provider-helm's code base into this project using Helm's Go library. However, I believe that integrating the Helm binary and executing it might reduce a lot of boilerplate code (e.g. the chart pulling code). We might loose a few things that provider-helm can do, but it's likely that we don't need the advanced features.
Advantages:
Releasecodehelmin the image leaves all helm logic in an external binaryDisadvantages:
helmhelmwork, e.g. caching storage volume (e.g. emptyDir) for pulling external charts in various versions.Out of Scope
Further links
Acceptance Criteria
No response
Implementation Ideas
I could imagine something like this:
helm upgrade my-release postgres --install --repo https://charts.bitnami.com/bitnami --version '11.1.23' --wait --namespace sv-postgresql-s-... --skip-crds --values /tmp/values/<uuid> --dependency-updatehelm upgrade, set the status conditions in the instance spec.