This is neccessary for dependency injections on helmclients.
DI on helmclients is neccessary for example in unit-test scenarios,
where you want to replace the helmclient implementation with a
mocked one.
We cannot make the helmclient itself injectable, because of the way
the helmclient handles Kubernetes namespaces. Instanciating a
helmclient has to be done in the same namespace the chart will get
installed to. That's a problem when trying to instanciate a helmclient
right from the start of this operator, since it would then have to
decide for one specified namespace and would need to stay there for
as long as the operator lives.
So we need to be able to dynamically generate helmclients whenever
a chart has to be installed or updated. That is what the wrapper
actually does.
This is neccessary for dependency injections on helmclients. DI on helmclients is neccessary for example in unit-test scenarios, where you want to replace the helmclient implementation with a mocked one.
We cannot make the helmclient itself injectable, because of the way the helmclient handles Kubernetes namespaces. Instanciating a helmclient has to be done in the same namespace the chart will get installed to. That's a problem when trying to instanciate a helmclient right from the start of this operator, since it would then have to decide for one specified namespace and would need to stay there for as long as the operator lives. So we need to be able to dynamically generate helmclients whenever a chart has to be installed or updated. That is what the wrapper actually does.