There are a few changes to the new dry-run handling:
1. Some documentation is added to help clarify what is happening
and what is expected.
2. DryRun is never changed by internal handling. If an API user
sets the property it is not changed by our code.
3. The behavior on contacting the server with false/none is made
consistent between install and upgrade.
Signed-off-by: Matt Farina <matt.farina@suse.com>
First, some notes about priority and how some code flow works.
For Helm handling values, the expected order of precidence is:
1. User specified values (e.g CLI)
2. Imported values
3. Parent chart values
4. Subchart values
Helm handles dependency values slightly differently. If there are dependencies
in the charts folder that are not marked as dependencies all of the values,
including nil values, are pulled in. If those charts are listed as a
dependency in the Chart.yaml file than they are processed for import handling.
Prior to the changes here, it caused nil values at the top level to NOT remove
values specified.
The changes:
1. The order of priority was chagned from the list above. Parnet chart values
would override specifically imported values. This is due to a change from
just over a year ago that introduced a bug. That was undone by changing the
precidence when maps were merged.
2. To handle merging while retaining the nil values, which was causing
inconsistent behavior, a new set of Merge functions were introduced. These
functions are just like coalesce except that they DO NOT remove nil/null values.
The new functions are used in a backward compatible manner meaning some new
functions were introduced that called them.
Specific issues fixed (that are known):
Closes#9027
Can now delete subkeys from charts when specified in the parent. This behavior
was previously inconsistent. Sometimes they could be deleted and other times
it did not work. Now it is consistent.
Closes#10899
Imported values (from library or other subcharts) are now used following the
order above.
The previous behavior was inconsistent. import-values using just a string
would import them. When named with a child/parent it did not work if the
parent already had a value. If string and named were mixed the imports
worked if the string happened first but just for the string not the named.
If the named parent/child went first then none of them worked for cases
where the parent already had a value. It was inconsistent and the tests
sometimes mirrored the functionality rather than expected behavior.
Tests for this fall into the sub-packages and are in the template tests
to verify it's happening in the output. Including having values passed
at the CLI as the ultimate highest priority to be used.
This relates to a fix that went in for #9940. The expected values there don't
fit the precedence above where the parent value would override the imported
value. That fix/change introduced more bugs.
Closes#10052
This is the case where imported values using the parent/child designation
just didn't work right. That has been fixed and there are tests. The underlying
issue had to do with the precedence order handling.
Note, a lot of tests were added. Hope we got it more right this time.
Signed-off-by: Matt Farina <matt.farina@suse.com>
When a helm command is run with the --dry-run flag, it will try to connect to the cluster
if the value is 'server' to be able to render lookup functions.
Closes helm#8137
Signed-off-by: Tapas Kapadia <tapaskapadia10@gmail.com>
When a helm command is run with the --dry-run flag, it will try to connect to the cluster
if the value is 'server' to be able to render lookup functions.
Closes helm#8137
Signed-off-by: Tapas Kapadia <tapaskapadia10@gmail.com>
If enabled the registryClient is set using a helper that accepts the TLS
flags. This keeps the client creation consistent accross the different
commands.
Signed-off-by: Soule BA <bah.soule@gmail.com>
When a helm command is run with the --dry-run flag, it will try to connect to the cluster
if the value is 'server' to be able to render lookup functions.
Closes#8137
Signed-off-by: Tapas Kapadia <tapaskapadia10@gmail.com>
When a helm command is run with the --dry-run-option=server flag, it will try to connect to the cluster
to be able to render lookup functions.
Closes#8137
Signed-off-by: Tapas Kapadia <tapaskapadia10@gmail.com>
When a helm command is run with the --dry-run flag, it will try to connect to the cluster
if the value is 'server' to be able to render lookup functions.
Closes#8137
Signed-off-by: Tapas Kapadia <tapaskapadia10@gmail.com>
When a helm command is run with the --dry-run flag, it will try to connect to the cluster
if the value is 'server' to be able to render lookup functions.
Closes helm#8137
Signed-off-by: Tapas Kapadia <tapaskapadia10@gmail.com>
When a helm command is run with the --dry-run flag, it will try to connect to the cluster
to be able to render lookup functions.
Closes#8137
Signed-off-by: Tapas Kapadia <tapaskapadia10@gmail.com>
Confirm that the current and updated revision numbers also match as part
of the readiness check. Add coverage for readiness scenarios where
StatefulSet status does not reflect the most recent generation of the
StatefulSet yet.
Also add additional logging around the sts transitions from non-ready to
ready.
Fixes: #10163
Signed-off-by: Dominic Evans <dominic.evans@uk.ibm.com>
When range support for OCI went in via #10527 it created a situation
where some lookups for a chart could cause a panic. This change
makes sure the registry client is available to lookup OCI charts
Signed-off-by: Matt Farina <matt.farina@suse.com>
Replicate the same logic in that was implementd in the upgrade action to handle SIGINT
Rename mutexes to isolate the variables
Signed-off-by: Stephane Moser <moser.sts@gmail.com>
Use mutex to lock the action to report the upstream function
Wrap logic to report to upstream function in the function reportToPerformUpgrade
Signed-off-by: Stephane Moser <moser.sts@gmail.com>
Change the logic to release Upgrade to handle SIGTERMs
Extract logic to 2 goroutine so it is possible to handle SIGTERMS and the release flow
Fix go style
Signed-off-by: Stephane Moser <moser.sts@gmail.com>
When #8156 was merged it had the side effect that all hooks were
run all the time. All the hooks were put in the flow of the
content rendered and sent to Kubernetes on every command.
For example, if you ran the following 2 commands the test hooks
would run:
helm create foo
helm install foo ./foo
This should not run any hooks. But, the generated test hook is run.
The change in this commit moves the writing of the hooks to output
or disk back into the template command rather than in a private
function within the actions. This is where it was for v3.2.
One side effect is that post renderers will not work on hooks. This
was the case in v3.2. Since this bug is blocking the release of v3.3.0
it is being rolled back. A refactor effort is underway for this section
of code. post renderer for hooks should be added back as part of that
work. Since post renderer hooks did not make it into a release it
is ok to roll it back for now.
There is code in the cmd/helm package that has been duplicated from
pkg/action. This is a temporary measure to fix the immediate bug
with plans to correct the situation as part of a refactor
of renderResources.
Signed-off-by: Matt Farina <matt@mattfarina.com>
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`.
Closes#7274
Signed-off-by: Cristian Klein <cristian.klein@elastisys.com>
* fix(template):Issue:helm template with --output-dir doesn't write template with a hook to file
Close#7836
Signed-off-by: Dong Gang <dong.gang@daocloud.io>
* fix go file style
Signed-off-by: Dong Gang <dong.gang@daocloud.io>
* fix go file style
Signed-off-by: Dong Gang <dong.gang@daocloud.io>
The error message returned from Kubernetes when APIs are
removed is not very informative. This PR adds additional
information to the user. It covers the current release manifest
APIs.
Partial #7219
Signed-off-by: Martin Hickey <martin.hickey@ie.ibm.com>
* docs: Update inline docs on action/upgrade.go
Signed-off-by: Matt Butcher <matt.butcher@microsoft.com>
* clarify atomic and cleanup-on-fail
Signed-off-by: Matt Butcher <matt.butcher@microsoft.com>
* updated the post-render documentation on action.Upgrade
Signed-off-by: Matt Butcher <matt.butcher@microsoft.com>
Upgrade Kubernetes libraries to v0.18.0
Add new lazy load KubernetesClientSet to avoid missing kubeconfig error
In kubernetes v1.18 kubeconfig validation was added. Minikube and Kind
both remove kubeconfig when stopping clusters. This causes and error
when running any helm commands because we initialize the client before
executing the command.
Signed-off-by: Adam Reese <adam@reese.io>
The 'helm upgrade' command was not checking if the cluster was reachable.
Also, 'helm upgrade --install' first checks if the release exists
already. If that check fails there is no point in continuing the
upgrade. This optimization avoids a second timeout of 30 seconds when
trying to do the upgrade.
Signed-off-by: Marc Khouzam <marc.khouzam@montreal.ca>