Can't upgrade helm charts after deployment about helm-controller

[ibrokethecloud]

Possible fix

[pulpo]

Same problem here!

[ibuildthecloud]

Can you give an example of a before and after HelmChart CR that fails?

[ibrokethecloud]

I suspect issue is the job uses helm install, which is perform when the args method parses over the helm spec.

https://github.com/rancher/helm-controller/blob/master/pkg/helm/controller.go#L321

To make it more idempotent, we should probably change the args to helm upgrade --install

[ibrokethecloud]

I dug around some more.. here is a sample when install is present

apiVersion: helm.cattle.io/v1
kind: HelmChart
metadata:
  name: wordpress
  namespace: default
spec:
  targetNamespace: default
  chart: wordpress
  repo: https://charts.bitnami.com/bitnami
  version: 7.4.0
  set:
    persistence.enabled: "false"
    mariadb.master.persistence.enabled: "false"
  helmVersion: v3

Initial install works fine. When I update the manifest to a new version

apiVersion: helm.cattle.io/v1
kind: HelmChart
metadata:
  name: wordpress
  namespace: default
spec:
  targetNamespace: default
  chart: wordpress
  repo: https://charts.bitnami.com/bitnami
  version: 9.0.0
  set:
    persistence.enabled: "false"
    mariadb.master.persistence.enabled: "false"
  helmVersion: v3

https://github.com/rancher/klipper-helm/blob/master/entry#L33

I suspect check should be [ $INSTALLED_VERSION != $VERSION ] for the upgrade branch to be executed.

Because of equality comparison the code falls through and goes back to the default execution:

https://github.com/rancher/klipper-helm/blob/master/entry#L33

After the tweak, the upgrade works as expected.

Already installed wordpress, upgrading
+ echo Already installed wordpress, upgrading
+ shift 1
+ helm_v3 --namespace default --repo https://charts.bitnami.com/bitnami --version 9.0.0 --set mariadb.master.persistence.enabled=false --set persistence.enabled=false upgrade wordpress wordpress

[brandonkal]

Perhaps using helm upgrade --install would work better.
It should be possible to modify values and redeploy.
I am seeing the same error: Error: cannot re-use a name that is still in use.

The weird thing is that I see this error after deleting the helm chart CR.
I made a change to a helm chart and it caused the helm-install job to fail. I deleted the HelmChart Custom Resource and attempted to reinstall when I saw the Custom Resource actually disappear.

Now I can't install that chart.

[riazarbi]

+1 for this issue. My use case is with jupyterhub on k3s. Deploying initially works fine, redeploying with updates image or what have breaks with Error: cannot re-use a name that is still in use.

On regular k8s we use the helm upgrade --install command for our workflow, so that will probably fix it.

[brokenjacobs]

I stopped using this and moved over to using HelmRelease from the fluxcd folks:
https://github.com/fluxcd/helm-operator-get-started

[gbonnefille]

Seems fixed in klipper-helm v0.2.4 and helm-controller v0.6.3 already ship klipper-helm v0.2.7.

Can this issue be closed? Or problem is still there?

[ShylajaDevadiga]

Verified in k3s version v1.19.2+k3s1, above issue is resolved.
Installed openebs chart to validate
INSTALLED_VERSION: 1.8.0
UPGRADED to VERSION: 1.9.0

kubectl describe pod  -n kube-system helm-install-openebs-24mm7  |grep VERSION
      VERSION:          1.8.0

kubectl describe pod  -n kube-system helm-install-openebs-g5vlf |grep VERSION
      VERSION:          1.9.0

[davidnuzik]

Closing this on behalf of @ShylajaDevadiga
@cjellick or I to fix her permissions.