Variable values `helm.sh/resource-policy` and `keep` are duplicately
defined in resource_policy.go (`resourcePolicyAnno` `keepPolicy`) and
resource_policy.go (`ResourcePolicyAnno` `KeepPolicy`), remove the
varibales in resource_policy.go to keep the code clean.
Signed-off-by: Liu Ming <hit_oak_tree@126.com>
A fix introduced in #8631 caused a bug in Windows builds due to
a type difference between POSIX and Windows environments. This
change corrects that problem and provides a code comment to warn
others.
Signed-off-by: Matt Farina <matt@mattfarina.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>
Previously, the `helm ls --$state` operation would display outdated
releases under certain conditions.
Given the following set of releases:
```
NAME REVISION UPDATED STATUS CHART APP VERSION NAMESPACE
bar 1 Wed Apr 8 16:54:39 2020 DEPLOYED bar-4.0.0 1.0 default
foo 1 Fri Feb 7 06:16:56 2020 DEPLOYED foo-0.1.0 1.0 default
foo 2 Mon May 4 07:16:56 2020 FAILED foo-0.1.0 1.0 default
foo 3 Mon May 4 07:20:00 2020 FAILED foo-0.1.0 1.0 default
foo 4 Tue May 5 08:16:56 2020 DEPLOYED foo-0.2.0 1.0 default
qux 1 Tue Jun 9 10:32:00 2020 DEPLOYED qux-4.0.3 1.0 default
qux 2 Tue Jun 9 10:57:00 2020 FAILED qux-4.0.3 1.0 default
```
`helm ls --failed` produced the following output:
```
NAME REVISION UPDATED STATUS CHART APP VERSION NAMESPACE
foo 3 Mon May 4 07:20:00 2020 FAILED foo-0.1.0 1.0 default
qux 2 Tue Jun 9 10:57:00 2020 FAILED qux-4.0.0 1.0 default
```
Including the `qux` release in that `helm ls --failed` output is not
controversial; the most recent revision of `qux` was not successful
and an operator should investigate.
Including the `foo` release in the output, however, is
questionable. Revision 3 of `foo` is _not_ the most recent release of
`foo`, and that FAILED release was fixed in a susubsequent upgrade. A
user may see that FAILED deploy and start taking inappropriate
action. Further, that issue was fixed months ago in this example --
troubleshooting an old deploy may not be safe if significant changes
have occurred. Concern over this behavior was raised in
https://github.com/helm/helm/issues/7495.
This behavior applied to all the state filter flags (--deployed,
--failed, --pending, etc.), and a user could pass multiple state
filter flags to a single command. The previous behavior can be
summarized as follows:
For each release name, all release revisions having any of the
supplied state flags were retrieved, and the most recent revision
among these was returned (regardless of whether a newer revision of an
unspecified state exists).
This change request alters the helm list action to match user
expectations such that only "current" releases are shown when
filtering on release state. After this change, the following output
would be produced by `helm ls --failed`:
```
NAME REVISION UPDATED STATUS CHART APP VERSION NAMESPACE
qux 2 Tue Jun 9 10:57:00 2020 FAILED qux-4.0.0 1.0 default
```
The command now returns only `qux` because it is the only "current" FAILED release.
This behavior change applies to all the state filters _except_
`superseded`, which now becomes a special case. By definition, at
least one newer release exists ahead of each superseded release. A
conditional is included in this change request to maintain the
preexisting behavior (return "most recent" superseded revison for
each release name) if the superseded state filter is requested.
---
Note that there is an alternate perspective that a state filter flag
should return all releases of a given state rather than only the
"current" releases. In the above example, `helm ls --failed` with this
approach would return the following:
```
NAME REVISION UPDATED STATUS CHART APP VERSION NAMESPACE
foo 2 Mon May 4 07:16:56 2020 FAILED foo-0.1.0 1.0 default
foo 3 Mon May 4 07:20:00 2020 FAILED foo-0.1.0 1.0 default
qux 2 Tue Jun 9 10:57:00 2020 FAILED qux-4.0.0 1.0 default
```
Multiple FAILED `foo` revisions are included in the output, unlike the current behavior.
This approach is logical and achievable. It allows a user to find
exactly what is requested: all historical releases of a given
state. In order to achieve continuity with helm behavior, however, a
new filter (something like "current") would probably need to be
implemented and become the new default.
Given current helm behavior as well as the comments in the #7495, I
did not pursue this approach.
---
Technical details:
- Moved list action state mask filter after latest release filter
Previously, the list operation in helm/pkg/action/list.go skipped
releases that were not covered by the state mask on _retrieval_ from
the Releases store:
```
results, err := l.cfg.Releases.List(func(rel *release.Release) bool {
// Skip anything that the mask doesn't cover
currentStatus := l.StateMask.FromName(rel.Info.Status.String())
if l.StateMask¤tStatus == 0 {
return false
}
...
```
8ea6b970ec/pkg/action/list.go (L154-L159)
While filtering on retrieval in this manner avoided an extra iteration
through the entire list to check on the supplied condition later, it
introduced the possibility of returning an outdated release to the
user because newer releases (that would have otherwise squashed
outdated releases in the `filterList` function) are simply not
included in the set of working records.
This change moves the state mask filtering process to _after_ the set
of current releases is built. Outdated, potentially misleading
releases are scrubbed out prior to the application of the state mask
filter.
As written, this state mask filtration (in the new `filterStateMask`
method on `*List`) incurs an additional, potentially expensive
iteration over the set of releases to return to the user. An
alternative approach could avoid that extra iteration and fit this
logic into the existing `filterList` function at the cost of making
`filterList` function a little harder to understand.
- Rename filterList to filterLatestReleases for clarity
Another function that filters the list is added, so update
to the more descriptive name here.
- List superseded releases without filtering for latest
This change makes superseded releases a special case, as they would
_never_ be displayed otherwise (by definition, as superseded releases have been
replaced by a newer release), so a conditional maintains current
behavior ("return newest superseded revision for each release name")
Fixes#7495.
Signed-off-by: Andrew Melis <andrewmelis@gmail.com>
A chart being installed which only contains CRDs and not
any templates tries to install the resources by default.
The resourceList which is used in this case does not check
if there are resources present in it or not. This commit
adds checks to those particular places where we need to check
if the size of resourceList > 0 during installation and deletion.
Signed-off-by: Vibhav Bobade <vibhav.bobde@gmail.com>
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>
* fix: fixed bug in Dependency.List()
A bug in Dependency.List() caused all compressed charts to flag their dependencies as "missing".
Closes#4431
Signed-off-by: Matt Butcher <matt.butcher@microsoft.com>
* removed some files from test fixtures
Signed-off-by: Matt Butcher <matt.butcher@microsoft.com>
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>
This complements the verification output fixed in #7706. On verify
there should be some detail about the verification rather than
no information.
Signed-off-by: Matt Farina <matt@mattfarina.com>
When using the --verify flag on the pull command the output was
an internal Go object rather than useful detail. This is a bug.
The output new displays who signed the chart along with the
hash.
Fixes#7624
Signed-off-by: Matt Farina <matt@mattfarina.com>
The memory driver is used for go tests. It can also be used from the
command-line by setting the environment variable HELM_DRIVER=memory.
In the latter case however, there was no way to pre-provision some
releases.
This commit introduces the HELM_MEMORY_DRIVER_DATA variable which
can be used to provide a colon-separated list of yaml files specifying
releases to provision automatically.
For example:
HELM_DRIVER=memory \
HELM_MEMORY_DRIVER_DATA=./testdata/releases.yaml \
helm list --all-namespaces
Signed-off-by: Marc Khouzam <marc.khouzam@montreal.ca>
This is a copy of the --disable-openapi-validation flag from the install command as introduced by Matthew Fisher.
See commit 67e57a5fbb
It allows upgrading releases without the need to validate the Kubernetes OpenAPI Schema.
Signed-off-by: Sebastian Voinea <sebastian.voinea@gmx.de>
The template command uses the memory driver. This driver now supports
namespaces, so the template code-path now specifies the namespace as
required by the memory driver.
Signed-off-by: Marc Khouzam <marc.khouzam@montreal.ca>
* Allow template output to use release name
helm template output command uses the chart name only when writing
templates to disk. This changes will also use the release name
to avoid colloiding the path when output nore than one release
of smae chart.
Signed-off-by: Martin Hickey <martin.hickey@ie.ibm.com>
* Update after review
Comment:
- https://github.com/helm/helm/pull/7503/files#r374130090
Signed-off-by: Martin Hickey <martin.hickey@ie.ibm.com>
These flags snuck in through a feature that was reverted and removed in Helm 2, but snuck into Helm 3.
They were never hooked up or used, so they were a no-op. This shouldn't affect anyone.
Signed-off-by: Matthew Fisher <matt.fisher@microsoft.com>
Use the same install order for hooks as for normal resources (non-hooks) for hooks with equal weight.
This makes resource handling more consistent and helps, when there are hook consisting of several resources like e.g. a service account and a job using this service account.
The sort functions are changed from an in place search to an out of place sort to avoid inout parameters.
Closes#7416.
Signed-off-by: Daniel Strobusch <1847260+dastrobu@users.noreply.github.com>
I was looking into the `get` command, and got tripped up by the
`Version` variable. It was unclear to me what Version represents, since
it's called REVISION when doing e.g., `helm list`.
But even after knowing this, it was not very clear to me why we
(implicitly) set the Version variable to 0 but never seem to use it.
`mhickey` explained to me on Slack that this gets the latest revision of
the release. Makes sense, but I added a comment about that too, to
clarify.
Signed-off-by: Andreas Lindhé <andreas@lindhe.io>
The 'helm install' command returned confusing error messages if a flag was misspecified (e.g. `helm install name chart --set value foo`). This lead to an error indicating that a name should be specified for the command. Now an explicit check is done on the number of arguments passed, returning a message indicating the invalid arguments (`foo` in the example`).
Closes#7225
Signed-off-by: Lennard Eijsackers <lennardeijsackers92@gmail.com>
The existing unit test doesn't cover the most important functionality
of filterList(). Adding that check. Separately test the specific
namespace-related behavior.
Remove the dead variable anotherOldOne.
Signed-off-by: Jakub Bielecki <jakub.bielecki@codilime.com>
When enabled, during the rendering process, this feature flag will not validate rendered templates against the Kubernetes OpenAPI Schema.
Signed-off-by: Matthew Fisher <matt.fisher@microsoft.com>
* fix(helm): add --description flag to 'helm install', 'helm upgrade', and 'helm uninstall'
When added, this flag allow us to add a custom description to the release. E.g. '--description "my custom description"'
Closes#7033
Signed-off-by: Juan Matias Kungfu de la Camara Beovide <juanmatias@gmail.com>
* fix(helm): fixed style issues on top of previous commit (3a43a9a487)
Closes#7033
Signed-off-by: Juan Matias Kungfu de la Camara Beovide <juanmatias@gmail.com>
* fix(helm): fixed wrong test issue on top of previous commit (3a43a9a)
Closes#7033
Signed-off-by: Juan Matias Kungfu de la Camara Beovide <juanmatias@gmail.com>
Fixes a few bugs related to tls config when installing charts:
1. When installing via relative path, tls config for the selected
repository was not being set.
2. The `--ca-file` flag was not being passed when constructing the
downloader.
3. Setting tls config was not checking for zero value in repo
config, causing flag to get overwritten with empty string.
There's still a few oddities here. I would expect that the flag
passed in on the command line would override the repo config, but
that's not currently the case. Also, we always set the cert, key
and ca files as a trio, when they should be set individually
depending on combination of flags / repo config.
Signed-off-by: James McElwain <jmcelwain@gmail.com>
The 'helm get values' has its own Run() method in the action package.
So, unlike the other 'get' variants, it needs to check for the
reachability of the cluster itself.
Signed-off-by: Marc Khouzam <marc.khouzam@montreal.ca>
When reporting an incompatible Kubernetes version, due to a version constraint from the kubeVersion field, the error message should report with the correct field name.
Signed-off-by: Daniel Strobusch <1847260+dastrobu@users.noreply.github.com>
This was a missed update when we updated the k8s libraries. I validated
that this works for CRD installs with v1beta1 and v1
Signed-off-by: Taylor Thomas <taylor.thomas@microsoft.com>
This blocks a particular error (caused by upstream discovery client),
printing a warning instead of failing. It's not a great solution, but is
a stop-gap until Client-Go gets fixed.
Closes#6361
Signed-off-by: Matt Butcher <matt.butcher@microsoft.com>
When 'helm3 lint <chart-name>.tar.gz' is run, this will lint Chart.yaml in the package
Closes#6535
Signed-off-by: Kamalashree N <nagaraj.kamalashree@gmail.com>
This is a v3 port of #6612. There have been significant changes due to the way
Helm 3 refactored things. I chose to add the method for getting logs to the
testing client because it seemed like something that someone using Helm
as an SDK might want. It takes a writer because it is more efficient (less
copying) and can write to any sort of buffer desired
Signed-off-by: Taylor Thomas <taylor.thomas@microsoft.com>
this was partially fixed in #6430 but the fix only
worked for values without nesting. this PR fixes it.
this is done by doing a deep copy of values rather
than a top level keys copy. deep copy ensures
values are not mutated during coalesce()
execution which leads to bugs like #6659
the deep copy code has been copied from:
https://gist.github.com/soroushjp/0ec92102641ddfc3ad5515ca76405f4d
which is in turn inspired by this stackoverflow answer:
http://stackoverflow.com/a/28579297/1366283
Signed-off-by: Karuppiah Natarajan <karuppiah7890@gmail.com>
This package mainly exists to workaround an issue in Go
where the serializer doesn't omit an empty value for time:
https://github.com/golang/go/issues/11939. This replaces all
release and hook object time references with the new time package
so things actually marshal correctly
Signed-off-by: Taylor Thomas <taylor.thomas@microsoft.com>
The recent init action config switched the order of how variables get bound
and where. This led to the namespace variable not being propagated down into
the calls to kubernetes.
Co-authored-by: Matthew Fisher <matt.fisher@microsoft.com>
Signed-off-by: Taylor Thomas <taylor.thomas@microsoft.com>
wawa0210
Du Zheng
Matt Farina
Matt Butcher
Mikuláš Dítě
Abhilash Gnan
Sebastian Sdorra
Matthew Fisher
Li Zhijian
Martin Hickey
Ling Samuel
Liu Ming
Manuel Rüger
Dong Gang
Dmitry Chepurovskiy
Andrew Melis
yxxhero
Cristian Klein
Karuppiah Natarajan
Adam Reese
Vibhav Bobade
Matthias Riegler
Matthew Morrissette
Elliot Maincourt
Adam Reese
Marc Khouzam
Jacob LeGrone
akash-gautam
Song Shukun
Sebastian Voinea
Taylor Thomas
Mike Tougeron
Josh Dolitsky
LongKB
Ilya Shaisultanov
Daniel Strobusch
海的澜色
Andreas Lindhé
bakito
Nick Lee
Josh Soref
raffaelespazzoli
Lennard Eijsackers
jabielecki
Juan Matías de la Cámara Beovide
Fabian Ruff
James McElwain
Andreas Stenius
Kamalashree Nagaraj
Aaron Mell