If two `helm upgrade`s are executed at the exact same time, then one of
the invocations will fail with "already exists".
If one `helm upgrade` is executed and a second one is started while the
first is in `pending-upgrade`, then the second invocation will create a
new release. Effectively, two helm invocations will simultaneously
change the state of Kubernetes resources -- which is scary -- then two
releases will be in `deployed` state -- which can cause other issues.
This commit fixes the corrupted storage problem, by introducting a poor
person's lock. If the last release is in a pending state, then helm will
abort. If the last release is in a pending state, due to a previously
killed helm, then the user is expected to do `helm rollback`.
This is a port to Helm v2 of #7322.
Signed-off-by: Cristian Klein <cristian.klein@elastisys.com>
There was a typo in a tiller error with "released named" message, I've changed it to "a release named". Also fix a unit-test for it.
Signed-off-by: Mikhail Kirpichev <mkirpic@gmail.com>
Upgrading a release and override existing values doesn't work as expected for nested values. Maps should be merged recursively, but currently maps are treated just like values and replaced at the top level.
If the existing values are:
```yaml
resources:
requests:
cpu: 400m
something: else
```
and an update is done with ```--set=resources.requests.cpu=500m```, it currently ends up as
```yaml
resources:
requests:
cpu: 500m
```
but it should have been
```yaml
resources:
requests:
cpu: 500m
something: else
```
This PR updates the way override values are merged into the existing set of values to merge rather than replace maps.
Closes: #4792
Signed-off-by: Morten Torkildsen <mortent@google.com>
While investigating a tiller crash on v2.10.0 (see recent comments in #3125), I pulled down the code
and wrote a test replicating the crash I was experiencing. I then
realized that the crash had been fixed, and was able to locate the fix
in #4630 after running a quck bisect.
Since there don't appear to be any tests that cover this crash, and I
had written one myself, I figured I might as well put up a PR for it.
Here's what the test failure on v2.10.0 looks like:
```
-- FAIL: TestUpdateReleasePendingInstall_Force (0.00s)
panic: runtime error: invalid memory address or nil pointer dereference [recovered]
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x50 pc=0x1d128d8]
goroutine 235 [running]:
testing.tRunner.func1(0xc420493c20)
/usr/local/Cellar/go/1.10/libexec/src/testing/testing.go:742 +0x29d
panic(0x1eb8d80, 0x2a12db0)
/usr/local/Cellar/go/1.10/libexec/src/runtime/panic.go:505 +0x229
k8s.io/helm/pkg/tiller.(*ReleaseServer).performUpdateForce(0xc4208210b0, 0xc4202c6dc0, 0x0, 0x0, 0x2174220)
/Users/mattrasmus/go/src/k8s.io/helm/pkg/tiller/release_update.go:166 +0x188
k8s.io/helm/pkg/tiller.(*ReleaseServer).UpdateRelease(0xc4208210b0, 0x2191780, 0xc420820f30, 0xc4202c6dc0, 0x29aeb90, 0x38, 0x2d2)
/Users/mattrasmus/go/src/k8s.io/helm/pkg/tiller/release_update.go:43 +0x245
k8s.io/helm/pkg/tiller.TestUpdateReleasePendingInstall_Force(0xc420493c20)
/Users/mattrasmus/go/src/k8s.io/helm/pkg/tiller/release_update_test.go:549 +0x120
testing.tRunner(0xc420493c20, 0x20e5c70)
/usr/local/Cellar/go/1.10/libexec/src/testing/testing.go:777 +0xd0
created by testing.(*T).Run
/usr/local/Cellar/go/1.10/libexec/src/testing/testing.go:824 +0x2e0
FAIL k8s.io/helm/pkg/tiller 0.118s
```
Signed-off-by: Matt Rasmus <mrasmus@betterworks.com>
resolves#4337
Merging maps inside of strings gets a bit tricky. When two
strings consisting of "{}" were being added together, this resulted in
"{}\n{}" instead of "{}" which is what we wanted. This led to YAML
parsing errors and showed up when the `--reuse-values` flag was used
when no overrides via `--set` were provided during install and/or
upgrade.
Resolves#3655
We were seeing that when running helm upgrade with the reuse-values
flag enabled that you could end up in the position where overrides
a.k.a computed values from previous revisions were not being saved on
the updated revision. This left us in a weird position where some
computed values would disappear mysteriously in the abyss. That
happened because computed values from previous revisions weren't merged
with the new computed values every time the reuse-values flag was used.
This PR merges computed values from the previous revisions so you don't
end up in that kind of conundrum.
When using `helm upgrade --install`, if the first release fails, Helm will respond with an error saying that it cannot upgrade from an unknown state.
With this feature, `helm upgrade --install --force` automates the same process as `helm delete && helm install --replace`. It will mark the previous release as DELETED, delete any existing resources inside Kubernetes, then replace it as if it was a fresh install. It will then mark the FAILED release as SUPERSEDED.
Fixes#2437
Two bugs were causing this behavior
- Tiller was marking the previous release superseded when an upgrade
failed.
- Upgrade was diffing against failed releases
Cristian Klein
Benjamen Keroack
Mikhail Kirpichev
Morten Torkildsen
Matt Rasmus
Matthew Fisher
Michelle Noorali
Michelle Noorali
Arash Deshmeh
Adam Reese
Maxim Ivanov
fibonacci1729