This repository has been archived by the owner on Nov 1, 2022. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Upgrade helm chart fails #1984
Labels
Comments
hiddeco
added
blocked-needs-validation
Issue is waiting to be validated before we can proceed
helm
labels
Apr 26, 2019
What is the status of the Helm release ( |
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. |
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. |
That would be great. Thanks |
Is it okay if I close this issue and we continue tracking it in the one I mentioned above? |
hiddeco
removed
the
blocked-needs-validation
Issue is waiting to be validated before we can proceed
label
Apr 26, 2019
Yes thx
…On Apr 26, 2019, 12:28 PM -0700, Hidde Beydals ***@***.***>, wrote:
Is it okay if I close this issue and we continue tracking it in the one I mentioned above?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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
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 runningkubectl logs -n default deploy/flux
.Additional context
Add any other context about the problem here, e.g
The text was updated successfully, but these errors were encountered: