updated helm to 3.3.0 & 2.16.10

[monotek]

Signed-off-by: André Bauer [email protected]

This pr updates helm to 2.16.10 (https://github.com/helm/helm/releases/tag/v2.16.10) and 3.3.0 (https://github.com/helm/helm/releases/tag/v3.3.0).

The 2.16.10 update includes a security fix:

• Helm v2.16.8 is a security release, patching a high-severity security vulnerability found in Go's crypto package affecting all versions of Helm 2 prior to 2.16.8.

Helm 3.3.0 brings a nice feature:

• allow a previously failed release to be upgraded (fix(helm): allow a previously failed release to be upgraded helm/helm#7653)

[stefanprodan]

@monotek Helm Operator doesn't use the Helm binaries, they are there for debugging purposes.

[monotek]

Damn.
So the makefile send me to the wrong place :D

Where shoud i look instead?

Edit: I'm not that go experienced but it looks like a helm-operator build imports from helm master?
https://github.com/fluxcd/helm-operator/blob/master/pkg/helm/v3/helm.go#L15-L21
So nothing to do but to wait for the next helm-operator release?

[runningman84]

@stefanprodan
are you going to update helm to 3.3.1? The latest cert-manager update needs helm 3.3.1

[hiddeco]

@runningman84 the Helm Operator is currently stuck, and likely will be stuck on the current Helm 3.x version due to Kubernetes client compatibility issues between Helm 2 and 3.

The helm-controller, which will replace the Helm Operator in the near future, includes Helm 3.3.1 and has about 90% feature parity with the Helm Operator at the moment.

[runningman84]

@hiddeco we would be happy to test the helm-controller... would it work with flux oder do we also need another component for flux?

I am afraid that for some time helm-operator has an old helm version which does not work with the latest cert-manager and the new project helm-controller is not stable...

[monotek]

@stefanprodan
Is this pr still wanted, even if it only updates the debugging tools?
If so, i would update to the latest versions. Otherwise i would close the pr...

[hiddeco]

@hiddeco we would be happy to test the helm-controller... would it work with flux oder do we also need another component for flux?

It needs the source-controller (which provides the helm-controller with chart artifacts) and helm-controller, and optionally the notification-controller if you want to receive notifications. The custom resources themselves (HelmRepository, GitRepository, and HelmRelease) can be synchronized by Flux v1.

Please have a look at the comparability table so that you are aware of the differences.

I am afraid that for some time helm-operator has an old helm version which does not work with the latest cert-manager and the new project helm-controller is not stable...

The API should be relatively stable now that all major feature implementations are done, as there is just there is a single issue pending before it reaches feature parity. With regard to the stability of the controller itself, it was designed and built from lessons learned from this project, and is at the moment already more performant and fault proof than the Helm Operator (it does not rely on dry-runs for example). It just has not seen (many) production environments yet.

[pierluigilenoci]

What about Helm v3.4.0?

[pierluigilenoci]

The v6.* of Grafana Helm Chart needs Helm >= v3.4.0
grafana-5.8.16...grafana-6.0.0#diff-f84e6aebb0

[hiddeco]

Helm 3.4.x still poses the same problems as described in #514 (comment).

[sharkymcdongles]

@runningman84 the Helm Operator is currently stuck, and likely will be stuck on the current Helm 3.x version due to Kubernetes client compatibility issues between Helm 2 and 3.

The helm-controller, which will replace the Helm Operator in the near future, includes Helm 3.3.1 and has about 90% feature parity with the Helm Operator at the moment.

Why are we supporting helm 2 at all? Helm 3 has been out now for over a year almost at this stage. There are more and more charts every day which need 3.4 or newer. What happens if the binary in the container is simply changed to a newer version?

[hiddeco]

@sharkymcdongles as pinpointed in the issues, the Helm Operator is in maintenance mode and we are working on a successor that has already reached feature parity with the Helm Operator as part of our bigger Flux2 effort.

What happens if the binary in the container is simply changed to a newer version?

This does not work, as we integrate with the Helm SDK and do not perform operations with the binary.