Skip to content
This repository has been archived by the owner on Nov 1, 2022. It is now read-only.

Upgrade helm chart fails #1984

Closed
derrickburns opened this issue Apr 25, 2019 · 6 comments
Closed

Upgrade helm chart fails #1984

derrickburns opened this issue Apr 25, 2019 · 6 comments
Labels

Comments

@derrickburns
Copy link
Contributor

Describe the bug
Weave Helm Operator appears to be attempting an install when it should be attempting an upgrade.

To Reproduce
I have a Helm chart installed via a HelmRelease, referenced via a GitHub url. Works fine.

I updated the chart in GitHub to include an additional service/deployment. I modified the values.yaml file.

When I look at the logs, Weave Helm Operator appears to attempt to install the new chart over the existing one. I expected it to attempt to upgrade the chart. Consequently, since the helm release name is the same, I get the

a release named foo already exists.\\nRun: helm ls --all foo

error message.
Expected behavior
Upgrade the chart in place.

Logs
If applicable, please provide logs of fluxd or the helm-operator. In a standard stand-alone installation of Flux, you'd get this by running kubectl logs -n default deploy/flux.

Additional context
Add any other context about the problem here, e.g

  • Flux version: docker.io/weaveworks/flux:1.12.0
  • Helm Operator version: docker.io/weaveworks/helm-operator:0.8.0
  • Kubernetes version: v1.11.8-eks-7c34c0
  • Git provider: GitHub
  • Container registry provider: DockerHub
@hiddeco hiddeco added blocked-needs-validation Issue is waiting to be validated before we can proceed helm labels Apr 26, 2019
@hiddeco
Copy link
Member

hiddeco commented Apr 26, 2019

What is the status of the Helm release (helm status <release>)? My suspicion is that it failed and therefore the Helm operator chooses to install rather than upgrade.

@derrickburns
Copy link
Contributor Author

derrickburns commented Apr 26, 2019

Ah. I see. You are correct.

If I make a change to a helm chart that breaks the install, Weave Helm Operator does not revert the change. So, the helm installation is left is a FAILED state.

I think that is not the desirable behavior.

@hiddeco
Copy link
Member

hiddeco commented Apr 26, 2019

We do this because rollbacks for stateful deployments can be dangerous, an enhancement has been described in #1960 and will be implemented in the future.

@derrickburns
Copy link
Contributor Author

That would be great. Thanks

@hiddeco
Copy link
Member

hiddeco commented Apr 26, 2019

Is it okay if I close this issue and we continue tracking it in the one I mentioned above?

@hiddeco hiddeco removed the blocked-needs-validation Issue is waiting to be validated before we can proceed label Apr 26, 2019
@derrickburns
Copy link
Contributor Author

derrickburns commented Apr 26, 2019 via email

@hiddeco hiddeco closed this as completed Apr 26, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

2 participants