profile
viewpoint
Matt Butcher technosophos @microsoft @azure Boulder, CO http://technosophos.com Creator of Helm, Glide, CNAB, Brigade, & PHP HTML5 parser. Authored "Go In Practice", "Illustrated Children's Guide to Kubernetes", and 7 other books. Ph.D.

helm/helm 17217

The Kubernetes Package Manager

Azure/draft 3903

A tool for developers to create cloud-native applications on Kubernetes.

brigadecore/brigade 1938

Event-based Scripting for Kubernetes.

helm/helm-classic 586

⚠️(OBSOLETE) Helm Classic v1

brigadecore/kashti 342

Kashti is a dashboard for your Brigade pipelines.

compose-spec/compose-spec 304

The Compose specification

michelleN/helm-tiller-rbac 60

Enable RBAC profiles for Tiller

Masterminds/vert 46

Command line version testing: Compare versions at the CLI for use in shell scripts and make files.

brigadecore/buck 33

Brigade Universal Controller for Kubernetes

brigadecore/brigade-k8s-gateway 21

Send Kubernetes events into a Brigade pipeline

issue commenthelm/helm

Unable to debug "lookup" function, as its disabled with `helm template`

It does appear that several months ago, someone changed the behavior of --dry-run to allow it to make some cluster requests. I do not think that this should have been done, but it is too late for me to change that now. (Originally, the --validate flag was to allow the user to request cluster-specific validation. Others appear to have lumped other network features in --dry-run, which was not my intent when I wrote it.)

If you want to PR a change in for adding lookup support in --dry-run, feel free. We'll audit the security of it at that point. It appears that we have an established user contract that allows some unsafe cluster operations during --dry-run at this point... so....

There are no plans for us to modify the helm template command. If you want to propose and then PR an --insecure-xxxx sort of thing, feel free. But we (the core maintainers) are not planning on working on this feature. I will say that I have reservations about altering the command in that way. But a proposal would give other core maintainers the ability to weigh in.

etsauer

comment created time in 6 days

issue commenthelm/helm

Unable to debug "lookup" function, as its disabled with `helm template`

Dry-run is NOT expected to interact with the cluster, and this is documented. All other similar functions and capabilities are also disabled for --dry-run.

etsauer

comment created time in 6 days

Pull request review commenthelm/helm

ref(tests): localize unit test fixtures to package

 limitations under the License. package action  import (-	"io/ioutil"-	"strings" 	"testing"++	"helm.sh/helm/v3/pkg/chart" )  func TestShow(t *testing.T) { 	client := NewShow(ShowAll)--	output, err := client.Run("../../cmd/helm/testdata/testcharts/alpine")-	if err != nil {-		t.Fatal(err)+	client.chart = &chart.Chart{

Ah! Yes! This is much cleaner for testing.

adamreese

comment created time in 10 days

issue commenthelm/helm

helm upgrade fails with spec.clusterIP: Invalid value: "": field is immutable

Oh! That is interesting. That should make the error easier to track down.

forainychen

comment created time in 11 days

pull request commenthelm/helm

Introduced fuzzing by adding first fuzzer

LOL... we do our best to fix bugs. Sorry we didn't get to your other one. I can't guarantee that we'll do it fast. But, you know, we have lots of open source contributors who try to help with stuff like that.

AdamKorcz

comment created time in 11 days

Pull request review commenthelm/helm

Add unit test for pkg/lint/rules/deprecations.go

 func TestValidateNoDeprecations(t *testing.T) { 		t.Errorf("Expected a v1 Pod to not be deprecated") 	} }++func TestError(t *testing.T) {

This name is ambiguous and should be replaced by something like TestDeprecatedAPIError

hs0210

comment created time in 11 days

pull request commenthelm/helm

Add --file-only flag to helm dep up to update only file:// dependencies

This PR needs both tests and an upstream issue that explains the feature.

That said, the reason we don't do this is that it creates a potential case in which SemVer negotiation does not work as expected. Two users may build the same chart at the same time, but if one uses --file-only they can get a different, potentially incompatible chart. You can even get a broken build if a --file-only prevents a fetch that would provide versions taht satisfy semver constraints that the local cache does not have.

Anymore, I'm not sure if we care about these cases. We used to try to prevent users from hitting edge cases like this, but so many PRs have been merged ignoring this guideline that I suppose we might as well do it here, too. Just be aware that this actually introduces new surface area for edge-case breakages.

AndyKilpatrick

comment created time in 11 days

pull request commenthelm/helm

WIP: Post Render args example

When it is marked WIP (Work In Progress), we do not put it in the review queue. I will remove the label and modify the title.

Please respect the fact that there are few of us and many, many issues/PRs. We work as fast as we can, but it is quite simply more work than we can handle.

acaire

comment created time in 11 days

pull request commenthelm/helm

WIP: Post Render args example

What is the status of this? It has been marked WIP for almost two months with no activity. Is the intention to carry this on to completion?

acaire

comment created time in 11 days

pull request commenthelm/helm

Introduced fuzzing by adding first fuzzer

Any update on this?

AdamKorcz

comment created time in 11 days

pull request commenthelm/helm

feat(install): introduce --adopt

I will re-iterate here that I do not agree with adding this set of features to Helm, and I believe it is outside of the scope of what a package manager is supposed to do.

sukimoyoi

comment created time in 11 days

issue closedhelm/helm

`lint` reports error when required value is not set in `values.yaml`

Description

If a chart has required settings (defined in values.schema.json), but those settings don't have a default provided in values.yaml, helm lint will always report an error, even when the values are set “externally” to the chart.

For instance, with the following chart:

$ tree -F .
.
├── Chart.yaml
├── templates/
├── values.schema.json
├── values.test.yaml
└── values.yaml

$ tail -n +1 Chart.yaml values.schema.json values.yaml values.test.yaml
==> Chart.yaml <==
---
apiVersion: v2
name: foobar
version: 0.1.0
appVersion: 0.1.0

==> values.schema.json <==
{
  "$schema": "https://json-schema.org/schema#",
  "type": "object",
  "properties": {
    "foo": {
      "type": "string"
    },
    "bar": {
      "type": "string"
    }
  },
  "additionalProperties": false,
  "required": [
    "foo",
    "bar"
  ]
}

==> values.yaml <==

==> values.test.yaml <==
---
foo: foo
bar: bar

This is an expected behavior:

$ helm lint .; echo $?
==> Linting .
[INFO] Chart.yaml: icon is recommended
[ERROR] values.yaml: - (root): foo is required
- (root): bar is required

[ERROR] templates/: values don't meet the specifications of the schema(s) in the following chart(s):
foobar:
- (root): foo is required
- (root): bar is required


Error: 1 chart(s) linted, 1 chart(s) failed
1

But this should not report any errors:

$ helm lint --set foo=foo --set bar=bar .; echo $?
==> Linting .
[INFO] Chart.yaml: icon is recommended
[ERROR] values.yaml: - (root): foo is required
- (root): bar is required


Error: 1 chart(s) linted, 1 chart(s) failed
1

$ helm lint --set foo=foo --set bar=bar .; echo $?
==> Linting .
[INFO] Chart.yaml: icon is recommended
[ERROR] values.yaml: - (root): foo is required
- (root): bar is required


Error: 1 chart(s) linted, 1 chart(s) failed
1

$ helm lint -f values.test.yaml .; echo $? 
==> Linting .
[INFO] Chart.yaml: icon is recommended
[ERROR] values.yaml: - (root): foo is required
- (root): bar is required


Error: 1 chart(s) linted, 1 chart(s) failed
1

Expected behavior

helm lint should not report an error when required values are set “externally”.

Installation details

Output of helm version: version.BuildInfo{Version:"v3.0.2", GitCommit:"19e47ee3283ae98139d98460de796c1be1e3975f", GitTreeState:"clean", GoVersion:"go1.13.5"} Output of kubectl version: not relevant Cloud Provider/Platform (AKS, GKE, Minikube etc.): not relevant

closed time in 11 days

johanfleury

issue commenthelm/helm

`lint` reports error when required value is not set in `values.yaml`

Closed by #7984

johanfleury

comment created time in 11 days

issue commenthelm/helm

Unable to debug "lookup" function, as its disabled with `helm template`

https://github.com/helm/helm/security/advisories/GHSA-q8q8-93cv-v6h8

etsauer

comment created time in 11 days

issue closedhelm/helm

Feature request: detailed error when certificates have expired

<!-- If you need help or think you have found a bug, please help us with your issue by entering the following information (otherwise you can delete this text): -->

Output of helm version: Client: &version.Version{SemVer:"v2.14.1", GitCommit:"5270352a09c7e8b6e8c9593002a73535276507c0", GitTreeState:"clean"} Server: &version.Version{SemVer:"v2.14.1", GitCommit:"5270352a09c7e8b6e8c9593002a73535276507c0", GitTreeState:"clean"}

Output of kubectl version: Client Version: version.Info{Major:"1", Minor:"13", GitVersion:"v1.13.7", GitCommit:"4683545293d792934a7a7e12f2cc47d20b2dd01b", GitTreeState:"clean", BuildDate:"2019-06-06T01:46:52Z", GoVersion:"go1.11.5", Compiler:"gc", Platform:"darwin/amd64"} Server Version: version.Info{Major:"1", Minor:"13+", GitVersion:"v1.13.6-gke.13", GitCommit:"fcbc1d20b6bca1936c0317743055ac75aef608ce", GitTreeState:"clean", BuildDate:"2019-06-19T20:50:07Z", GoVersion:"go1.11.5b4", Compiler:"gc", Platform:"linux/amd64"}

Cloud Provider/Platform (AKS, GKE, Minikube etc.): GKE

Bug:

Our helm/tiller is set up with tls verification. We found that all of a sudden, with no change to kubectl or helm versions, all our helm upgrades were hanging until they timed out with "context deadline exceeded". This also affected helm ls, helm version, etc.

It took us a lot of digging around without much help to realize that the certificates might have just expired. After that we did a helm init --upgrade ... with the new certs and it worked.

Some detailed error outputs would have saved many hours of grief.

closed time in 12 days

PaulFlorea

issue commenthelm/helm

Feature request: detailed error when certificates have expired

Turns out that this is all hidden deep inside of Kubernetes' client-go package. I can't find anywhere were we could hook in and detect this condition. I think that later versions of client-go might have fixed the hanging behavior. But a change to SSL certificate handling needs to be made in client-go, not Helm.

So I am marking this as closed/won't fix.

PaulFlorea

comment created time in 12 days

issue commenthelm/helm

Unable to debug "lookup" function, as its disabled with `helm template`

Lookup is intentionally disabled for security reasons. There is no plan to change this behavior.

etsauer

comment created time in 12 days

issue commentbrigadecore/community

Add Kent Rancourt (krancour) as a core maintainer on brigadecore/brigade

Sorry, I didn't see the one in Brigade. I only thought to look here. My bad. I see that @lukepatrick also voted there. 🤦 Sorry for the inconvenience.

technosophos

comment created time in 14 days

issue commentbrigadecore/community

Add Kent Rancourt (krancour) as a core maintainer on brigadecore/brigade

To vote, simply add a +1 comment or statement on this issue.

technosophos

comment created time in 14 days

issue openedbrigadecore/community

Add Kent Rancourt (krancour) as a core maintainer on brigadecore/brigade

This issue formally invites the maintainers to vote on adding @krancour as a core maintainer on the brigadecore/brigade project. Kent has been the principal driver for all of the Brigade Next planning work, and is currently writing the proposal for Brigade 2.0. Having him as a core maintainer is a critical part of the plan to make Brigade 2 a reality.

We do not have a formally defined method of voting in new candidates but the guidelines require that we have a supermajority vote. The current list of eligible voters are: @technosophos @adamreese @mumoshu @vdice @radu-matei @lukepatrick

The vote will be opened until June 1, 2020 or until at least 4 core maintainers approve. I would like to suggest that as an additional stipulation, at least one such person must not be from Microsoft. Therefore, I will not cast my vote until after one non-MS person has voted.

created time in 14 days

PR opened helm/helm

feat: Detect missing selector during lint awaiting review v3.x

<!-- Thanks for sending a pull request! Here are some tips for you:

  1. Make sure to read the Contributing Guide before submitting your PR: https://github.com/helm/helm/blob/master/CONTRIBUTING.md
  2. If this PR closes another issue, add 'closes #<issue number>' somewhere in the PR summary. GitHub will automatically close that issue when this PR gets merged. Alternatively, adding 'refs #<issue number>' will not close the issue, but help provide the reviewer more context.-->

What this PR does / why we need it:

This issue closes #1990 by adding a quick test for matchLabels or matchExpressions in specific Kubernetes kinds. This was a requested feature because so many Helm issues were being filed because of malformed charts. I don't know if this is any longer necessary. If not, we can probably just close-won't-fix #1990.

Because a chart with no valid selector is illegal, this is an error. It catches matchLabels and matchSelectors (instead of just selector) because the requirement is that one of these two most be present. These are the fields frequently left off by chart authors.

Like all other chart lints, this does not enforce anything other than that the strings are present.

Special notes for your reviewer:

This change will definitely cause some charts that did not pass before to fail a lint now. However, those charts would have been broken had they been installed.

If applicable:

  • [ ] this PR contains documentation
  • [x] this PR contains unit tests
  • [ ] this PR has been tested for backwards compatibility

Closes #1990 Signed-off-by: Matt Butcher matt.butcher@microsoft.com

+94 -1

0 comment

2 changed files

pr created time in 17 days

create barnchtechnosophos/k8s-helm

branch : feat/1990-match-labels-lint

created branch time in 17 days

pull request commenthelm/helm

fix: Ignore local path when `--repo` is provided

Oh! I did think of another option. We could mark --repo as deprecated, and add another flag that instituted this new behavior. That would get us around the SemVer constraints, and allow us to do what (I still agree) is the better UX. /cc @mattfarina

mforutan

comment created time in 19 days

Pull request review commenthelm/helm

fix(template): fix the bug when helm template with flag --output-dir

 func newTemplateCmd(cfg *action.Configuration, out io.Writer) *cobra.Command {  	return cmd }++// write the <data> to <output-dir>/<name>. <append> controls if the file is created or content will be appended+func writeToFile(outputDir string, name string, data string, append bool) error {+	outfileName := strings.Join([]string{outputDir, name}, string(filepath.Separator))++	err := ensureDirectoryForFile(outfileName)+	if err != nil {+		return err+	}++	f, err := createOrOpenFile(outfileName, append)+	if err != nil {+		return err+	}++	defer f.Close()++	_, err = f.WriteString(fmt.Sprintf("---\n# Source: %s\n%s\n", name, data))++	if err != nil {+		return err+	}++	fmt.Printf("wrote %s\n", outfileName)

Is this left-over debugging output, or is this supposed to be here? If it is intended to be here, it should use fmt.Fprintf() and send the results to whatever the command declares as out. This allows other things to override STDOUT with another ouput.

donggangcj

comment created time in 19 days

Pull request review commenthelm/helm

fix(template): fix the bug when helm template with flag --output-dir

 func newTemplateCmd(cfg *action.Configuration, out io.Writer) *cobra.Command { 			if rel != nil { 				var manifests bytes.Buffer 				fmt.Fprintln(&manifests, strings.TrimSpace(rel.Manifest))--				if !client.DisableHooks {-					for _, m := range rel.Hooks {-						fmt.Fprintf(&manifests, "---\n# Source: %s\n%s\n", m.Path, m.Manifest)+				newDir := client.OutputDir

This section should probably be put in a new function or several new functions. The cyclomatic complexity of newTemplateCmd is already too high, and this makes it really hard to read.

donggangcj

comment created time in 19 days

pull request commenthelm/helm

fix(storage): Deployed, DeployedAll, and History methods should return correct errors.

@mattfarina what is your opinion on whether changing error types/messages constitutes breaking changes?

jmontroy90

comment created time in 19 days

pull request commenthelm/helm

fix: Ignore local path when `--repo` is provided

Unless @mattfarina can show otherwise, this is a SemVer breaking change, and is deferred until Helm 4. For the record, I do agree that this is better UX.... but it still breaks our SemVer policy.

mforutan

comment created time in 19 days

issue commenthelm/helm

Error: validation: chart.metadata is required when using --repo

I have pointed out on that issue that changing precedence order is a breaking change, and cannot be done until Helm 4: https://github.com/helm/helm/blob/master/CONTRIBUTING.md#semantic-versioning

I agree that --repo should take precedence... but the fact of the matter is that it does not, and never has. Changing it mid-stream would violate our SemVer constraints.

That covers only part of this issue's surface area, so I am leaving this issue open for that, and will mark the #7862 bug as deferred until Helm 4.

pniederlag

comment created time in 19 days

issue commenthelm/helm

Bug: `--repo` should takes precedence over local folder

On what grounds are you calling this a bug, @mattfarina? If this was explicitly a design choice made years ago. Looking at the repo, both Helm2 and Helm3 have always behaved this way. Changing it now constitutes a breaking change, since the behavior users have come to expect will change drastically (a completely different chart can be fetched).

If you want to call it a bug, you need to justify why it is a bug, not that it is "better UX". Better UX can be deferred until Helm 4. By my reading, changing this behavior violates the first bullet point on the braking changes list: https://github.com/helm/helm/blob/master/CONTRIBUTING.md#semantic-versioning

And thus I have played my role as the SemVer enforcer for the day.

mforutan

comment created time in 19 days

issue commenthelm/helm

helm dep update is not working correctly if the repository is not present in the local repo list

The relevant change was introduced in Helm 3: https://github.com/helm/helm/blob/512544b9abbc75418348b76037fee3156ea1d3bd/pkg/downloader/manager.go#L469-L478

It used to be the case that helm repo up also returned an error when the chart repos were not all locally cached. As part of a bigger change, the error message was replaced with a partial cache of the remote repository. But the partial change introduced this particular bug.

There are two options:

  1. We can re-instate the old behavior, and make helm dep up return an error if it does not find the repository locally.
  2. We can rewrite the downloader.Manager to fully support what equates to "anonymous" caches.

I am not sure I understand the reason for the anonymous caches in the first place. Maybe @bacongobbler can provide the context for that. Because I am reluctant to do a rewrite of this logic, my gut feel is that we should just return an error on helm dep up if the repository does not exist locally.

In either case, we need to decide what to do about helm dep build, which is more likely able to get away with an anonymous cache, since it does not need to do SemVer negotiation, and since it does not need to generate a lock file.

technosophos

comment created time in 19 days

pull request commenthelm/helm

Remove hasAllRepos function

So far, this issue has helped us turn up a longstanding bug in helm dep update. It may be the case that helm dep update should require a valid local repo just like helm dep build does. Ironically, helm dep build may not need the local repo if the lock file is present.

kristinnardal2

comment created time in 19 days

issue openedhelm/helm

helm dep update is not working correctly if the repository is not present in the local repo list

<!-- If you need help or think you have found a bug, please help us with your issue by entering the following information (otherwise you can delete this text): -->

Output of helm version:

version.BuildInfo{Version:"v3.2+unreleased", GitCommit:"324c7cbc076f4e673e246f6cdc97939815e4af13", GitTreeState:"clean", GoVersion:"go1.14.2"}

Output of kubectl version:

Client Version: version.Info{Major:"1", Minor:"16+", GitVersion:"v1.16.6-beta.0", GitCommit:"e7f962ba86f4ce7033828210ca3556393c377bcc", GitTreeState:"clean", BuildDate:"2020-01-15T08:26:26Z", GoVersion:"go1.13.5", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.2", GitCommit:"52c56ce7a8272c798dbc29846288d7cd9fbae032", GitTreeState:"clean", BuildDate:"2020-04-30T20:19:45Z", GoVersion:"go1.13.9", Compiler:"gc", Platform:"linux/amd64"}

Cloud Provider/Platform (AKS, GKE, Minikube etc.):

Kind


While looking into #8028, we discovered a long-standing issue in helm dep update.

The correct behavior:

If a repository is added to Helm (e.g. helm repo add ...), and then a chart in that repository is referenced in a dependencies section of a Chart.yaml, the resolver correctly does SemVer comparisons and pins to a specific version of the chart.

The incorrect behavior:

If a repository is NOT PRESENT when helm dep up is run (or when helm dep build is called and no Chart.lock is present), then the chart repository is fetched out-of-band. While the proper version is resolved for the chart that is updated locally, the Version field in the chart.lock is incorrectly set to the SemVer query, not to the resolved version.

Reproducing

Create a chart with helm create and then add this to the Chart.yaml:

dependencies:
- name: argo-cd
  version: ">=1.8.0"
  repository: https://argoproj.github.io/argo-helm

Make sure that the chart repository is not already in your helm repo list. If it is, remove it and clear the cache directory.

$ helm repo list
Error: no repositories to show

Now do a helm dep build or helm dep update.

$ helm dep build
Saving 1 charts
Downloading argo-cd from repo https://argoproj.github.io/argo-helm
Deleting outdated charts

Now look at the generated Chart.lock:

dependencies:
- name: argo-cd
  repository: https://argoproj.github.io/argo-helm
  version: '>=1.8.0'
digest: sha256:1801b6e7653b3cba2a78902a8268a453f376bed85b1ff81b96ac88c4aacbea2c
generated: "2020-05-13T17:05:42.497865-06:00"

Note that version is wrong. It should not be a range query. It should be the specific version that the dependency resolver found.

Why is this a problem? Because the lockfile is no longer doing its job: It is no longer pinning to a single version.

Note that in the above example, the actual version that it downloaded was version 3.2.0. So it is correctly negotiating the SemVer range, but it is not generating the correct value for Chart.lock

This issue may impact Helm 2, but it definitely impacts Helm 3, all versions.

created time in 19 days

push eventhelm/helm

小明同学

commit sha decab8ea2e6ea4b31560aff50abb2676a67ec8ba

fix: upgrade using --force shoud not run patch logic (#8000) fix helm/helm#7999 Signed-off-by: Liu Ming <hit_oak_tree@126.com>

view details

push time in 19 days

PR merged helm/helm

fix: upgrade using --force shoud not run patch logic size/M

fix helm/helm#7999

+15 -15

0 comment

1 changed file

liuming-dev

pr closed time in 19 days

issue closedhelm/helm

"failed to create patch: The order in patch list" when helm upgrade using --force

<!-- If you need help or think you have found a bug, please help us with your issue by entering the following information (otherwise you can delete this text): -->

Output of helm version: version.BuildInfo{Version:"v3.1.2", GitCommit:"d878d4d45863e42fd5cff6743294a11d28a9abce", GitTreeState:"clean", GoVersion:"go1.13.8"}

Output of kubectl version: Client Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.2", GitCommit:"52c56ce7a8272c798dbc29846288d7cd9fbae032", GitTreeState:"clean", BuildDate:"2020-04-16T23:35:15Z", GoVersion:"go1.14.2", Compiler:"gc", Platform:"darwin/amd64"} Server Version: version.Info{Major:"1", Minor:"15", GitVersion:"v1.15.5", GitCommit:"20c265fef0741dd71a66480e35bd69f18351daea", GitTreeState:"clean", BuildDate:"2019-10-15T19:07:57Z", GoVersion:"go1.12.10", Compiler:"gc", Platform:"linux/amd64"}

Cloud Provider/Platform (AKS, GKE, Minikube etc.):

Situation part of deployment yaml

      hostAliases:
      - hostnames:
        - cpc0101.mongodb
        ip: 10.153.44.147
      - hostnames:
        - cpc0102.mongodb
        ip: 10.153.52.224
      - hostnames:
        - cpc0103.mongodb
        ip: 10.153.53.139
      - hostnames:
        - cpc0201.mongodb
        ip: 10.153.52.63
      - hostnames:
        - cpc0202.mongodb
        ip: 10.153.58.52
      - hostnames:
        - cpc0203.mongodb
        ip: 10.153.60.75
      - hostnames:
        - cpc0301.mongodb
        ip: 10.144.122.209
      - hostnames:
        - cpc0302.mongodb
        ip: 10.144.125.225
      - hostnames:
        - cpc0303.mongodb
        ip: 10.144.126.191
      - hostnames:
        - cpcrank0101.mongodb
        ip: 10.153.52.61
      - hostnames:
        - cpcrank0102.mongodb
        ip: 10.142.69.176
      - hostnames:
        - cpcrank0103.mongodb
        ip: 10.153.52.62
      - hostnames:
        - cpcrank0201.mongodb
        ip: 10.144.97.235
      - hostnames:
        - cpcrank0202.mongodb
        ip: 10.142.32.128
      - hostnames:
        - cpcrank0203.mongodb
        ip: 10.134.107.236
      - hostnames:
        - cpcrank0301.mongodb
        ip: 10.144.126.213
      - hostnames:
        - cpcrank0302.mongodb
        ip: 10.144.127.168
      - hostnames:
        - cpcrank0303.mongodb
        ip: 10.152.99.208
      - hostnames:
        - dev.kafka.broker1
        ip: 10.134.55.168
      - hostnames:
        - dev.kafka.broker2
        ip: 10.134.73.192
      - hostnames:
        - dev.kafka.broker3
        ip: 10.134.73.196
      - hostnames:
        - download.ceph.com
        ip: 158.69.68.124
      - hostnames:
        - galaxywirelesslog01.mongodb
        ip: 10.144.122.209
      - hostnames:
        - galaxywirelesslog02.mongodb
        ip: 10.144.125.225
      - hostnames:
        - galaxywirelesslog03.mongodb
        ip: 10.144.126.191
      - hostnames:
        - hourreport0101.mongodb
        ip: 10.144.126.213
      - hostnames:
        - hourreport0102.mongodb
        ip: 10.144.127.168
      - hostnames:
        - hourreport0103.mongodb
        ip: 10.152.99.208
      - hostnames:
        - hourreport0201.mongodb
        ip: 10.144.14.227
      - hostnames:
        - hourreport0202.mongodb
        ip: 10.152.100.136
      - hostnames:
        - hourreport0203.mongodb
        ip: 10.152.105.194
      - hostnames:
        - hourreport0301.mongodb
        ip: 10.134.97.208
      - hostnames:
        - hourreport0302.mongodb
        ip: 10.134.110.147
      - hostnames:
        - hourreport0303.mongodb
        ip: 10.142.79.219
      - hostnames:
        - idea0101.mongodb
        ip: 10.153.44.147
      - hostnames:
        - idea0102.mongodb
        ip: 10.153.52.224
      - hostnames:
        - idea0103.mongodb
        ip: 10.153.53.139
      - hostnames:
        - idea0201.mongodb
        ip: 10.153.52.63
      - hostnames:
        - idea0202.mongodb
        ip: 10.153.58.52
      - hostnames:
        - idea0203.mongodb
        ip: 10.153.60.75
      - hostnames:
        - idea0301.mongodb
        ip: 10.144.122.209
      - hostnames:
        - idea0302.mongodb
        ip: 10.144.125.225
      - hostnames:
        - idea0303.mongodb
        ip: 10.144.126.191
      - hostnames:
        - kafka.broker1
        ip: 10.142.115.37
      - hostnames:
        - kafka.broker2
        ip: 10.142.112.29
      - hostnames:
        - kafka.broker3
        ip: 10.152.58.89
      - hostnames:
        - kuaitoureport01.mongodb
        ip: 10.153.52.191
      - hostnames:
        - kuaitoureport02.mongodb
        ip: 10.153.54.239
      - hostnames:
        - kuaitoureport03.mongodb
        ip: 10.153.61.232
      - hostnames:
        - noclickcpc0101.mongodb
        ip: 10.153.44.147
      - hostnames:
        - noclickcpc0102.mongodb
        ip: 10.153.52.224
      - hostnames:
        - noclickcpc0103.mongodb
        ip: 10.153.53.139
      - hostnames:
        - noclickcpc0201.mongodb
        ip: 10.153.52.63
      - hostnames:
        - noclickcpc0202.mongodb
        ip: 10.153.58.52
      - hostnames:
        - noclickcpc0203.mongodb
        ip: 10.153.60.75
      - hostnames:
        - noclickcpc0301.mongodb
        ip: 10.144.122.209
      - hostnames:
        - noclickcpc0302.mongodb
        ip: 10.144.125.225
      - hostnames:
        - noclickcpc0303.mongodb
        ip: 10.144.126.191
      - hostnames:
        - qa.bizlog0101.mongodb
        ip: 10.134.97.208
      - hostnames:
        - qa.bizlog0102.mongodb
        ip: 10.142.79.219
      - hostnames:
        - qa.bizlog0103.mongodb
        ip: 10.134.110.147
      - hostnames:
        - qa.bizlog0201.mongodb
        ip: 10.134.97.208
      - hostnames:
        - qa.bizlog0202.mongodb
        ip: 10.142.79.219
      - hostnames:
        - qa.bizlog0203.mongodb
        ip: 10.134.110.147
      - hostnames:
        - qa.bizlog0301.mongodb
        ip: 10.144.14.227
      - hostnames:
        - qa.bizlog0302.mongodb
        ip: 10.152.100.136
      - hostnames:
        - qa.bizlog0303.mongodb
        ip: 10.152.105.194
      - hostnames:
        - qa.bizlog0401.mongodb
        ip: 10.144.14.227
      - hostnames:
        - qa.bizlog0402.mongodb
        ip: 10.152.100.136
      - hostnames:
        - qa.bizlog0403.mongodb
        ip: 10.152.105.194
      - hostnames:
        - qa.bizlog0501.mongodb
        ip: 10.144.14.227
      - hostnames:
        - qa.bizlog0502.mongodb
        ip: 10.152.100.136
      - hostnames:
        - qa.bizlog0503.mongodb
        ip: 10.152.105.194
      - hostnames:
        - qa.bizlog0601.mongodb
        ip: 10.144.14.227
      - hostnames:
        - qa.bizlog0602.mongodb
        ip: 10.152.100.136
      - hostnames:
        - qa.bizlog0603.mongodb
        ip: 10.152.105.194
      - hostnames:
        - qa.iflow01.mongodb
        ip: 10.134.109.215
      - hostnames:
        - qa.iflow02.mongodb
        ip: 10.134.110.238
      - hostnames:
        - qa.iflow03.mongodb
        ip: 10.134.115.189
      - hostnames:
        - qa.memcache1.dubhe
        ip: 10.153.57.225
      - hostnames:
        - qa.memcache2.dubhe
        ip: 10.153.57.229
      - hostnames:
        - qa.memcache3.dubhe
        ip: 10.153.60.164
      - hostnames:
        - qa.scxbigquery.mysql
        ip: 10.152.70.220
      - hostnames:
        - querykey0101.mongodb
        ip: 10.153.52.61
      - hostnames:
        - querykey0102.mongodb
        ip: 10.153.52.62
      - hostnames:
        - querykey0103.mongodb
        ip: 10.153.52.63
      - hostnames:
        - querykey0201.mongodb
        ip: 10.144.97.235
      - hostnames:
        - querykey0202.mongodb
        ip: 10.142.32.128
      - hostnames:
        - querykey0203.mongodb
        ip: 10.134.107.236
      - hostnames:
        - querykey0301.mongodb
        ip: 10.144.126.213
      - hostnames:
        - querykey0302.mongodb
        ip: 10.144.127.168
      - hostnames:
        - querykey0303.mongodb
        ip: 10.152.99.208
      - hostnames:
        - regionreport0101.mongodb
        ip: 10.144.126.213
      - hostnames:
        - regionreport0102.mongodb
        ip: 10.144.127.168
      - hostnames:
        - regionreport0103.mongodb
        ip: 10.152.99.208
      - hostnames:
        - regionreport0201.mongodb
        ip: 10.144.14.227
      - hostnames:
        - regionreport0202.mongodb
        ip: 10.152.100.136
      - hostnames:
        - regionreport0203.mongodb
        ip: 10.152.105.194
      - hostnames:
        - regionreport0301.mongodb
        ip: 10.134.97.208
      - hostnames:
        - regionreport0302.mongodb
        ip: 10.134.110.147
      - hostnames:
        - regionreport0303.mongodb
        ip: 10.142.79.219
      - hostnames:
        - xuridailyspend01.mongodb
        ip: 10.144.103.130
      - hostnames:
        - xuridailyspend02.mongodb
        ip: 10.144.99.237
      - hostnames:
        - xuridailyspend03.mongodb
        ip: 10.144.119.212
      - hostnames:
        - xuriopt01.mongodb
        ip: 10.148.35.161
      - hostnames:
        - xuriopt02.mongodb
        ip: 10.148.38.193
      - hostnames:
        - xuriopt03.mongodb
        ip: 10.148.33.147
      - hostnames:
        - xurispend01.mongodb
        ip: 10.144.103.130
      - hostnames:
        - xurispend02.mongodb
        ip: 10.144.99.237
      - hostnames:
        - xurispend03.mongodb
        ip: 10.144.119.212

there are duplicated ips in hostAliases, and use helper.Replace(target.Namespace, target.Name, true, target.Object) to deploy, everything goes well.

when switching to helm, use helm upgrade with the default values, error is returned failed to create patch: The order in patch list: ...

~/.kube » helm history janus-fe --kubeconfig ./pre -n bizqa                                                                apple@liuming216448
REVISION	UPDATED                 	STATUS    	CHART                  	APP VERSION	DESCRIPTION
1       	Tue Apr 21 21:31:22 2020	superseded	thanos-deployment-1.0.0	1.16.0     	Install complete
2       	Sun Apr 26 15:57:09 2020	failed    	thanos-deployment-1.0.0	1.16.0     	Upgrade "janus-fe" failed: failed to create patch: The order in patch list:
        	                        	          	                       	           	[map[hostnames:[cpc0101.mongodb] ip:10.153.44.147] map[hostnames:[noclickcpc0101.mongodb] ip:10.153.44.147] map[hostnames:[idea0201.mongodb] ip:10.153.52.63] map[hostnames:[cpc0201.mongodb] ip:10.153.52.63] map[hostnames:[querykey0103.mongodb] ip:10.153.52.63] map[hostnames:[noclickcpc0201.mongodb] ip:10.153.52.63] map[hostnames:[noclickcpc0202.mongodb] ip:10.153.58.52] map[hostnames:[idea0202.mongodb] ip:10.153.58.52] map[hostnames:[noclickcpc0203.mongodb] ip:10.153.60.75] map[hostnames:[cpc0203.mongodb] ip:10.153.60.75] map[hostnames:[idea0203.mongodb] ip:10.153.60.75] map[hostnames:[cpc0301.mongodb] ip:10.144.122.209] map[hostnames:[idea0301.mongodb] ip:10.144.122.209] map[hostnames:[galaxywirelesslog02.mongodb] ip:10.144.125.225] map[hostnames:[cpc0302.mongodb] ip:10.144.125.225] map[hostnames:[galaxywirelesslog03.mongodb] ip:10.144.126.191] map[hostnames:[cpc0303.mongodb] ip:10.144.126.191] map[hostnames:[cpcrank0103.mongodb] ip:10.153.52.62] map[hostnames:[querykey0102.mongodb] ip:10.153.52.62] map[hostnames:[cpcrank0201.mongodb] ip:10.144.97.235] map[hostnames:[querykey0201.mongodb] ip:10.144.97.235] map[hostnames:[querykey0301.mongodb] ip:10.144.126.213] map[hostnames:[hourreport0101.mongodb] ip:10.144.126.213] map[hostnames:[regionreport0101.mongodb] ip:10.144.126.213] map[hostnames:[querykey0302.mongodb] ip:10.144.127.168] map[hostnames:[regionreport0102.mongodb] ip:10.144.127.168] map[hostnames:[querykey0303.mongodb] ip:10.152.99.208] map[hostnames:[regionreport0103.mongodb] ip:10.152.99.208] map[hostnames:[hourreport0103.mongodb] ip:10.152.99.208] map[hostnames:[cpcrank0303.mongodb] ip:10.152.99.208] map[hostnames:[qa.bizlog0401.mongodb] ip:10.144.14.227] map[hostnames:[regionreport0201.mongodb] ip:10.144.14.227] map[hostnames:[qa.bizlog0601.mongodb] ip:10.144.14.227] map[hostnames:[hourreport0201.mongodb] ip:10.144.14.227] map[hostnames:[regionreport0202.mongodb] ip:10.152.100.136] map[hostnames:[hourreport0202.mongodb] ip:10.152.100.136] map[hostnames:[qa.bizlog0302.mongodb] ip:10.152.100.136] map[hostnames:[qa.bizlog0602.mongodb] ip:10.152.100.136] map[hostnames:[qa.bizlog0402.mongodb] ip:10.152.100.136] map[hostnames:[qa.bizlog0502.mongodb] ip:10.152.100.136] map[hostnames:[qa.bizlog0303.mongodb] ip:10.152.105.194] map[hostnames:[regionreport0203.mongodb] ip:10.152.105.194] map[hostnames:[qa.bizlog0603.mongodb] ip:10.152.105.194] map[hostnames:[qa.bizlog0503.mongodb] ip:10.152.105.194] map[hostnames:[hourreport0203.mongodb] ip:10.152.105.194] map[hostnames:[qa.bizlog0403.mongodb] ip:10.152.105.194] map[hostnames:[regionreport0301.mongodb] ip:10.134.97.208] map[hostnames:[qa.bizlog0201.mongodb] ip:10.134.97.208] map[hostnames:[hourreport0301.mongodb] ip:10.134.97.208] map[hostnames:[qa.bizlog0203.mongodb] ip:10.134.110.147] map[hostnames:[regionreport0302.mongodb] ip:10.134.110.147] map[hostnames:[regionreport0303.mongodb] ip:10.142.79.219] map[hostnames:[qa.bizlog0102.mongodb] ip:10.142.79.219] map[hostnames:[hourreport0303.mongodb] ip:10.142.79.219] map[hostnames:[xurispend01.mongodb] ip:10.144.103.130] map[hostnames:[xuridailyspend01.mongodb] ip:10.144.103.130] map[hostnames:[xuridailyspend02.mon...
3       	Sun Apr 26 15:58:39 2020	failed    	thanos-deployment-1.0.0	1.16.0     	Upgrade "janus-fe" failed: failed to create patch: The order in patch list:
        	                        	          	                       	           	[map[hostnames:[cpc0101.mongodb] ip:10.153.44.147] map[hostnames:[noclickcpc0101.mongodb] ip:10.153.44.147] map[hostnames:[idea0201.mongodb] ip:10.153.52.63] map[hostnames:[cpc0201.mongodb] ip:10.153.52.63] map[hostnames:[querykey0103.mongodb] ip:10.153.52.63] map[hostnames:[noclickcpc0201.mongodb] ip:10.153.52.63] map[hostnames:[noclickcpc0202.mongodb] ip:10.153.58.52] map[hostnames:[idea0202.mongodb] ip:10.153.58.52] map[hostnames:[noclickcpc0203.mongodb] ip:10.153.60.75] map[hostnames:[cpc0203.mongodb] ip:10.153.60.75] map[hostnames:[idea0203.mongodb] ip:10.153.60.75] map[hostnames:[cpc0301.mongodb] ip:10.144.122.209] map[hostnames:[idea0301.mongodb] ip:10.144.122.209] map[hostnames:[galaxywirelesslog02.mongodb] ip:10.144.125.225] map[hostnames:[cpc0302.mongodb] ip:10.144.125.225] map[hostnames:[galaxywirelesslog03.mongodb] ip:10.144.126.191] map[hostnames:[cpc0303.mongodb] ip:10.144.126.191] map[hostnames:[cpcrank0103.mongodb] ip:10.153.52.62] map[hostnames:[querykey0102.mongodb] ip:10.153.52.62] map[hostnames:[cpcrank0201.mongodb] ip:10.144.97.235] map[hostnames:[querykey0201.mongodb] ip:10.144.97.235] map[hostnames:[querykey0301.mongodb] ip:10.144.126.213] map[hostnames:[hourreport0101.mongodb] ip:10.144.126.213] map[hostnames:[regionreport0101.mongodb] ip:10.144.126.213] map[hostnames:[querykey0302.mongodb] ip:10.144.127.168] map[hostnames:[regionreport0102.mongodb] ip:10.144.127.168] map[hostnames:[querykey0303.mongodb] ip:10.152.99.208] map[hostnames:[regionreport0103.mongodb] ip:10.152.99.208] map[hostnames:[hourreport0103.mongodb] ip:10.152.99.208] map[hostnames:[cpcrank0303.mongodb] ip:10.152.99.208] map[hostnames:[qa.bizlog0401.mongodb] ip:10.144.14.227] map[hostnames:[regionreport0201.mongodb] ip:10.144.14.227] map[hostnames:[qa.bizlog0601.mongodb] ip:10.144.14.227] map[hostnames:[hourreport0201.mongodb] ip:10.144.14.227] map[hostnames:[regionreport0202.mongodb] ip:10.152.100.136] map[hostnames:[hourreport0202.mongodb] ip:10.152.100.136] map[hostnames:[qa.bizlog0302.mongodb] ip:10.152.100.136] map[hostnames:[qa.bizlog0602.mongodb] ip:10.152.100.136] map[hostnames:[qa.bizlog0402.mongodb] ip:10.152.100.136] map[hostnames:[qa.bizlog0502.mongodb] ip:10.152.100.136] map[hostnames:[qa.bizlog0303.mongodb] ip:10.152.105.194] map[hostnames:[regionreport0203.mongodb] ip:10.152.105.194] map[hostnames:[qa.bizlog0603.mongodb] ip:10.152.105.194] map[hostnames:[qa.bizlog0503.mongodb] ip:10.152.105.194] map[hostnames:[hourreport0203.mongodb] ip:10.152.105.194] map[hostnames:[qa.bizlog0403.mongodb] ip:10.152.105.194] map[hostnames:[regionreport0301.mongodb] ip:10.134.97.208] map[hostnames:[qa.bizlog0201.mongodb] ip:10.134.97.208] map[hostnames:[hourreport0301.mongodb] ip:10.134.97.208] map[hostnames:[qa.bizlog0203.mongodb] ip:10.134.110.147] map[hostnames:[regionreport0302.mongodb] ip:10.134.110.147] map[hostnames:[regionreport0303.mongodb] ip:10.142.79.219] map[hostnames:[qa.bizlog0102.mongodb] ip:10.142.79.219] map[hostnames:[hourreport0303.mongodb] ip:10.142.79.219] map[hostnames:[xurispend01.mongodb] ip:10.144.103.130] map[hostnames:[xuridailyspend01.mongodb] ip:10.144.103.130] map[hostnames:[xuridailyspend02.mon...
4       	Sun Apr 26 16:33:17 2020	failed    	thanos-deployment-1.0.0	1.16.0     	Upgrade "janus-fe" failed: failed to create patch: The order in patch list:
        	                        	          	                       	           	[map[hostnames:[cpc0101.mongodb] ip:10.153.44.147] map[hostnames:[noclickcpc0101.mongodb] ip:10.153.44.147] map[hostnames:[idea0201.mongodb] ip:10.153.52.63] map[hostnames:[cpc0201.mongodb] ip:10.153.52.63] map[hostnames:[querykey0103.mongodb] ip:10.153.52.63] map[hostnames:[noclickcpc0201.mongodb] ip:10.153.52.63] map[hostnames:[noclickcpc0202.mongodb] ip:10.153.58.52] map[hostnames:[idea0202.mongodb] ip:10.153.58.52] map[hostnames:[noclickcpc0203.mongodb] ip:10.153.60.75] map[hostnames:[cpc0203.mongodb] ip:10.153.60.75] map[hostnames:[idea0203.mongodb] ip:10.153.60.75] map[hostnames:[cpc0301.mongodb] ip:10.144.122.209] map[hostnames:[idea0301.mongodb] ip:10.144.122.209] map[hostnames:[galaxywirelesslog02.mongodb] ip:10.144.125.225] map[hostnames:[cpc0302.mongodb] ip:10.144.125.225] map[hostnames:[galaxywirelesslog03.mongodb] ip:10.144.126.191] map[hostnames:[cpc0303.mongodb] ip:10.144.126.191] map[hostnames:[cpcrank0103.mongodb] ip:10.153.52.62] map[hostnames:[querykey0102.mongodb] ip:10.153.52.62] map[hostnames:[cpcrank0201.mongodb] ip:10.144.97.235] map[hostnames:[querykey0201.mongodb] ip:10.144.97.235] map[hostnames:[querykey0301.mongodb] ip:10.144.126.213] map[hostnames:[hourreport0101.mongodb] ip:10.144.126.213] map[hostnames:[regionreport0101.mongodb] ip:10.144.126.213] map[hostnames:[querykey0302.mongodb] ip:10.144.127.168] map[hostnames:[regionreport0102.mongodb] ip:10.144.127.168] map[hostnames:[querykey0303.mongodb] ip:10.152.99.208] map[hostnames:[regionreport0103.mongodb] ip:10.152.99.208] map[hostnames:[hourreport0103.mongodb] ip:10.152.99.208] map[hostnames:[cpcrank0303.mongodb] ip:10.152.99.208] map[hostnames:[qa.bizlog0401.mongodb] ip:10.144.14.227] map[hostnames:[regionreport0201.mongodb] ip:10.144.14.227] map[hostnames:[qa.bizlog0601.mongodb] ip:10.144.14.227] map[hostnames:[hourreport0201.mongodb] ip:10.144.14.227] map[hostnames:[regionreport0202.mongodb] ip:10.152.100.136] map[hostnames:[hourreport0202.mongodb] ip:10.152.100.136] map[hostnames:[qa.bizlog0302.mongodb] ip:10.152.100.136] map[hostnames:[qa.bizlog0602.mongodb] ip:10.152.100.136] map[hostnames:[qa.bizlog0402.mongodb] ip:10.152.100.136] map[hostnames:[qa.bizlog0502.mongodb] ip:10.152.100.136] map[hostnames:[qa.bizlog0303.mongodb] ip:10.152.105.194] map[hostnames:[regionreport0203.mongodb] ip:10.152.105.194] map[hostnames:[qa.bizlog0603.mongodb] ip:10.152.105.194] map[hostnames:[qa.bizlog0503.mongodb] ip:10.152.105.194] map[hostnames:[hourreport0203.mongodb] ip:10.152.105.194] map[hostnames:[qa.bizlog0403.mongodb] ip:10.152.105.194] map[hostnames:[regionreport0301.mongodb] ip:10.134.97.208] map[hostnames:[qa.bizlog0201.mongodb] ip:10.134.97.208] map[hostnames:[hourreport0301.mongodb] ip:10.134.97.208] map[hostnames:[qa.bizlog0203.mongodb] ip:10.134.110.147] map[hostnames:[regionreport0302.mongodb] ip:10.134.110.147] map[hostnames:[regionreport0303.mongodb] ip:10.142.79.219] map[hostnames:[qa.bizlog0102.mongodb] ip:10.142.79.219] map[hostnames:[hourreport0303.mongodb] ip:10.142.79.219] map[hostnames:[xurispend01.mongodb] ip:10.144.103.130] map[hostnames:[xuridailyspend01.mongodb] ip:10.144.103.130] map[hostnames:[xuridailyspend02.mon...
5       	Sun Apr 26 17:00:43 2020	failed    	thanos-deployment-1.0.0	1.16.0     	Upgrade "janus-fe" failed: failed to create patch: The order in patch list:
        	                        	          	                       	           	[map[hostnames:[cpc0101.mongodb] ip:10.153.44.147] map[hostnames:[noclickcpc0101.mongodb] ip:10.153.44.147] map[hostnames:[idea0201.mongodb] ip:10.153.52.63] map[hostnames:[cpc0201.mongodb] ip:10.153.52.63] map[hostnames:[querykey0103.mongodb] ip:10.153.52.63] map[hostnames:[noclickcpc0201.mongodb] ip:10.153.52.63] map[hostnames:[noclickcpc0202.mongodb] ip:10.153.58.52] map[hostnames:[idea0202.mongodb] ip:10.153.58.52] map[hostnames:[noclickcpc0203.mongodb] ip:10.153.60.75] map[hostnames:[cpc0203.mongodb] ip:10.153.60.75] map[hostnames:[idea0203.mongodb] ip:10.153.60.75] map[hostnames:[cpc0301.mongodb] ip:10.144.122.209] map[hostnames:[idea0301.mongodb] ip:10.144.122.209] map[hostnames:[galaxywirelesslog02.mongodb] ip:10.144.125.225] map[hostnames:[cpc0302.mongodb] ip:10.144.125.225] map[hostnames:[galaxywirelesslog03.mongodb] ip:10.144.126.191] map[hostnames:[cpc0303.mongodb] ip:10.144.126.191] map[hostnames:[cpcrank0103.mongodb] ip:10.153.52.62] map[hostnames:[querykey0102.mongodb] ip:10.153.52.62] map[hostnames:[cpcrank0201.mongodb] ip:10.144.97.235] map[hostnames:[querykey0201.mongodb] ip:10.144.97.235] map[hostnames:[querykey0301.mongodb] ip:10.144.126.213] map[hostnames:[hourreport0101.mongodb] ip:10.144.126.213] map[hostnames:[regionreport0101.mongodb] ip:10.144.126.213] map[hostnames:[querykey0302.mongodb] ip:10.144.127.168] map[hostnames:[regionreport0102.mongodb] ip:10.144.127.168] map[hostnames:[querykey0303.mongodb] ip:10.152.99.208] map[hostnames:[regionreport0103.mongodb] ip:10.152.99.208] map[hostnames:[hourreport0103.mongodb] ip:10.152.99.208] map[hostnames:[cpcrank0303.mongodb] ip:10.152.99.208] map[hostnames:[qa.bizlog0401.mongodb] ip:10.144.14.227] map[hostnames:[regionreport0201.mongodb] ip:10.144.14.227] map[hostnames:[qa.bizlog0601.mongodb] ip:10.144.14.227] map[hostnames:[hourreport0201.mongodb] ip:10.144.14.227] map[hostnames:[regionreport0202.mongodb] ip:10.152.100.136] map[hostnames:[hourreport0202.mongodb] ip:10.152.100.136] map[hostnames:[qa.bizlog0302.mongodb] ip:10.152.100.136] map[hostnames:[qa.bizlog0602.mongodb] ip:10.152.100.136] map[hostnames:[qa.bizlog0402.mongodb] ip:10.152.100.136] map[hostnames:[qa.bizlog0502.mongodb] ip:10.152.100.136] map[hostnames:[qa.bizlog0303.mongodb] ip:10.152.105.194] map[hostnames:[regionreport0203.mongodb] ip:10.152.105.194] map[hostnames:[qa.bizlog0603.mongodb] ip:10.152.105.194] map[hostnames:[qa.bizlog0503.mongodb] ip:10.152.105.194] map[hostnames:[hourreport0203.mongodb] ip:10.152.105.194] map[hostnames:[qa.bizlog0403.mongodb] ip:10.152.105.194] map[hostnames:[regionreport0301.mongodb] ip:10.134.97.208] map[hostnames:[qa.bizlog0201.mongodb] ip:10.134.97.208] map[hostnames:[hourreport0301.mongodb] ip:10.134.97.208] map[hostnames:[qa.bizlog0203.mongodb] ip:10.134.110.147] map[hostnames:[regionreport0302.mongodb] ip:10.134.110.147] map[hostnames:[regionreport0303.mongodb] ip:10.142.79.219] map[hostnames:[qa.bizlog0102.mongodb] ip:10.142.79.219] map[hostnames:[hourreport0303.mongodb] ip:10.142.79.219] map[hostnames:[xurispend01.mongodb] ip:10.144.103.130] map[hostnames:[xuridailyspend01.mongodb] ip:10.144.103.130] map[hostnames:[xuridailyspend02.mon...

Dive into source code

It seems to use patch method helper.Patch to perform upgrade, and the above error is returned.

when given --force, it seems to try to use helper.Replace, but was blocked by

patch, patchType, err := createPatch(target, currentObj)

where the error is returned.

https://github.com/helm/helm/blob/master/pkg/kube/client.go

func updateResource(c *Client, target *resource.Info, currentObj runtime.Object, force bool) error {
	var (
		obj    runtime.Object
		helper = resource.NewHelper(target.Client, target.Mapping)
		kind   = target.Mapping.GroupVersionKind.Kind
	)

	patch, patchType, err := createPatch(target, currentObj)
	if err != nil {
		return errors.Wrap(err, "failed to create patch")
	}

	if patch == nil || string(patch) == "{}" {
		c.Log("Looks like there are no changes for %s %q", target.Mapping.GroupVersionKind.Kind, target.Name)
		// This needs to happen to make sure that tiller has the latest info from the API
		// Otherwise there will be no labels and other functions that use labels will panic
		if err := target.Get(); err != nil {
			return errors.Wrap(err, "failed to refresh resource information")
		}
		return nil
	}

	// if --force is applied, attempt to replace the existing resource with the new object.
	if force {
		obj, err = helper.Replace(target.Namespace, target.Name, true, target.Object)
		if err != nil {
			return errors.Wrap(err, "failed to replace object")
		}
		c.Log("Replaced %q with kind %s for kind %s\n", target.Name, currentObj.GetObjectKind().GroupVersionKind().Kind, kind)
	} else {
		// send patch to server
		obj, err = helper.Patch(target.Namespace, target.Name, patchType, patch, nil)
		if err != nil {
			return errors.Wrapf(err, "cannot patch %q with kind %s", target.Name, kind)
		}
	}

	target.Refresh(obj, true)
	return nil
}

Solution

So, I think that the source code could be refactor to the following one, maybe

func updateResource(c *Client, target *resource.Info, currentObj runtime.Object, force bool) error {
	var (
		obj    runtime.Object
		helper = resource.NewHelper(target.Client, target.Mapping)
		kind   = target.Mapping.GroupVersionKind.Kind
	)

	// if --force is applied, attempt to replace the existing resource with the new object.
	if force {
		var err error
		obj, err = helper.Replace(target.Namespace, target.Name, true, target.Object)
		if err != nil {
			return errors.Wrap(err, "failed to replace object")
		}
		c.Log("Replaced %q with kind %s for kind %s\n", target.Name, currentObj.GetObjectKind().GroupVersionKind().Kind, kind)
	} else {
		patch, patchType, err := createPatch(target, currentObj)
		if err != nil {
			return errors.Wrap(err, "failed to create patch")
		}

		if patch == nil || string(patch) == "{}" {
			c.Log("Looks like there are no changes for %s %q", target.Mapping.GroupVersionKind.Kind, target.Name)
			// This needs to happen to make sure that tiller has the latest info from the API
			// Otherwise there will be no labels and other functions that use labels will panic
			if err := target.Get(); err != nil {
				return errors.Wrap(err, "failed to refresh resource information")
			}
			return nil
		}
		// send patch to server
		obj, err = helper.Patch(target.Namespace, target.Name, patchType, patch, nil)
		if err != nil {
			return errors.Wrapf(err, "cannot patch %q with kind %s", target.Name, kind)
		}
	}

	target.Refresh(obj, true)
	return nil
}

Result the error was eliminated,and everything goes well.

closed time in 19 days

liuming-dev

issue commenthelm/helm

helm upgrade fails with spec.clusterIP: Invalid value: "": field is immutable

@GaramNick there is not enough info about the service you are using for us to reproduce your error.

forainychen

comment created time in 19 days

issue commenthelm/helm

helm upgrade fails with spec.clusterIP: Invalid value: "": field is immutable

I cannot reproduce @IdanAdar 's case on master.

forainychen

comment created time in 19 days

issue commenthelm/helm

helm upgrade fails with spec.clusterIP: Invalid value: "": field is immutable

So https://github.com/helm/helm/issues/6378#issuecomment-557746499 is correct. Please read that before continuing on with this issue. If clusterIP: "" is set, Kubernetes will assign an IP. On the next Helm upgrade, if clusterIP:"" again, it will give the error above, because it appears to Kubernetes that you are trying to reset the IP. (Yes, Kubernetes modifies the spec: section of a service!)

When the Create method bypasses the 3-way diff, it sets clusterIP: "" instead of setting it to the IP address assigned by Kubernetes.

To reproduce:

$ helm create issue7956
$ # edit issue7956/templates/service.yaml and add `clusterIP: ""` under `spec:`
$ helm upgrade --install issue7956 issue7956
...
$ helm upgrade issue7956 issue7956
Error: UPGRADE FAILED: cannot patch "issue-issue7956" with kind Service: Service "issue-issue7956" is invalid: spec.clusterIP: Invalid value: "": field is immutable

The second time you run the upgrade, it will fail.

forainychen

comment created time in 19 days

issue commenthelm/helm

helm upgrade fails with spec.clusterIP: Invalid value: "": field is immutable

I am reviewing the issue with @adamreese , and we think it is the patch that @n1koo identified. The Create method will bypass the normal 3-way diff on the Service, which will result in the service's clusterIP being set to "" instead of the value populated by Kubernetes. As a result, the manifest sent to the API server appears to be resetting the cluster IP, which is illegal on a service (and definitely not what the user intended).

We're still looking into this and I will update if we learn more.

forainychen

comment created time in 19 days

pull request commenthelm/helm

pkg/chart/chart.go: add unit test for Root

This PR needs to reference an issue number, then it can be merged. I am marking it as "Approved" though it should not be merged until an issue is created and linked here.

littleroad

comment created time in 19 days

pull request commenthelm/helm

helpers: escape name

This needs an issue # and a test. PRs must reference an issue. I left a note about using | quote instead of | toJson.

greut

comment created time in 19 days

Pull request review commenthelm/helm

helpers: escape name

 app.kubernetes.io/managed-by: {{ .Release.Service }} Selector labels */}} {{- define "<CHARTNAME>.selectorLabels" -}}-app.kubernetes.io/name: {{ include "<CHARTNAME>.name" . }}+app.kubernetes.io/name: {{ include "<CHARTNAME>.name" . | toJson }}

I think that instead of | toJson, you want | quote

greut

comment created time in 19 days

pull request commenthelm/helm

added option --insecure-skip-tls-verify for helm pull, install and upgrade, addresses #7875

Any way we can add tests for this? Otherwise, it looks good. It will be a relief to have this flag consistent across commands

xvzf

comment created time in 19 days

pull request commentcnabio/cnab-go

WIP: Introduce a digest validation interface and docker implementation

What should we do with this PR?

jeremyrickard

comment created time in 19 days

issue commenthelm/helm

'helm repo update {REPO} ' feature

Note that if anyone attempts to change this behavior, you will need to solve the case where a chart in Repo A references a chart in Repo B, and Repo A gets locally updated but Repo B does not.

carrodher

comment created time in 20 days

issue commenthelm/helm

Upgrade fails but status is “deployed”?

Also, including the output of helm history would help. It is entirely possible that you didn't get far enough into the deployment for the upgrade's release record to even be created. Thus the "deployed" release would be your last release, not the current failed release. Hard to say, though. We'd need more information.

IdanAdar

comment created time in 20 days

push eventhelm/helm

Niels de Vos

commit sha bf12ae39344aef012927ab391eb26ddd3a30ae30

scripts: do not use optional 'which' command in get-helm installation (#8048) When installing Helm, the following warning gets printed on the console: Downloading https://get.helm.sh/helm-v2.16.6-linux-amd64.tar.gz Preparing to install helm and tiller into /usr/local/bin helm installed into /usr/local/bin/helm tiller installed into /usr/local/bin/tiller main: line 178: which: command not found Run 'helm init' to configure helm. The 'which' command is optional, and not always installed on all environments (like a Fedora container). Instead, use 'command -v' to detect if the executable is in the $PATH. Signed-off-by: Niels de Vos <ndevos@redhat.com>

view details

push time in 20 days

PR merged helm/helm

scripts: do not use optional 'which' command in get-helm installation size/XS

When installing Helm, the following warning gets printed on the console:

Downloading https://get.helm.sh/helm-v2.16.6-linux-amd64.tar.gz
Preparing to install helm and tiller into /usr/local/bin
helm installed into /usr/local/bin/helm
tiller installed into /usr/local/bin/tiller
main: line 178: which: command not found
Run 'helm init' to configure helm.

The 'which' command is optional, and not always installed on all environments (like a Fedora container). Instead, use 'command -v' to detect if the executable is in the $PATH.

+2 -2

0 comment

2 changed files

nixpanic

pr closed time in 20 days

pull request commenthelm/helm

refactor: storage secret and configmap keep exactly the same code impletation details in some behaviors

This also needs an issue number to an issue that describes the reason why this should be refactored.

liuming-dev

comment created time in 20 days

pull request commenthelm/helm

refactor: extract the logic in `LoadDir` into `LoadFile`

There is no issue mentioned on this PR. Please include the issue number that this resolves.

liuming-dev

comment created time in 20 days

issue closedhelm/helm

helm repo add --repository-cache not considered

helm3 (tested with 3.1.3 or 3.2.1)

helm3 repo add test https://xxxx --repository-config /tmp/test/repositories.yaml --repository-cache /tmp/test/repository

repo correctly added into the fresh repositories.yaml into in /tmp/test but cache is not copied under /tmp/test/repository , but still created under $XDG_CACHE_HOME PS: even if directory /tmp/test/repository does exist before. Also tested with sub directories of XDG_CACHE_HOME. it fails too.

closed time in 20 days

cridam

issue commenthelm/helm

helm repo add --repository-cache not considered

Verified that it is a duplicate. There is an open PR that is stalled, but will hopefully make it into 3.3.0. Closing this so that all discussion can continue on #7141. Thanks!

cridam

comment created time in 20 days

pull request commenthelm/helm

Use repository-cache if specified

Just checking in on this one. I looked at the code a little more carefully today, and it appears to catch the main cases I could find. I would like to get this in for 3.3.0 if possible.

trondhindenes

comment created time in 20 days

issue commenthelm/helm

helm repo add --repository-cache not considered

I think this is a duplicate of #7141, which I have looked at but not fixed yet.

cridam

comment created time in 20 days

issue commenthelm/helm

error validating data: kind not set

The command helm install test . is not the correct command for Helm 2. https://v2.helm.sh/docs/helm/#helm-install

gionapaolini

comment created time in 20 days

issue commenthelm/helm

Upgrade only subchart

An upgrade should not be deleting a namespace. So something is wrong there.

The usual way Helm works during upgrade is by reading your current Helm installation, and then generating the updated version, comparing them, and only installing the changes. So, in a nutshell, Helm does by default what you are asking for.

Probably the best way to fix this is to try to find out why it is deleting things on upgrade.

davorceman

comment created time in 20 days

pull request commenthelm/helm

feat: lint info on template spacing failure

@mattfarina This is the reference: https://helm.sh/docs/chart_best_practices/templates/

The recommendation originally came from the Go post when they added {{-, though the main champions of this have been the chart maintainers, not us.

For my part, I don't particularly care. I'm not really one of the best practices maintainers. If you would like to push for a change there, that's fine. But it does seem sensible that the best practices be recommended by the linter. Thus the request for this change.

Anymore, I'm not really sure what the point of the linter is. Is it to recommend best practices or try to catch errors? Because most of the lints are not errors per se, but just stylistic things. However, the chart repo tools have a lot more lints that aren't present here. After working on lints for a month, and having people complain about just about everything, I am not all that convinced that the linter adds much true value if people are just gonna argue to death that "the linter is too chatty" "I don't want the linter to warn me about X" "this should be an error, not a warning, because I don't like it" etc.

The original point of the linter was to enforce best practices in charts. Do we care about that or not? Because it feels an awful lot like what people want the linter to do is tell them their chart is fine according to their own personal standards for what they want to be fine.

technosophos

comment created time in 20 days

push eventhelm/helm

Matt Butcher

commit sha 59eed4e81f840bfa8a5aa69fc6c92471413609eb

feat: make the linter coalesce the passed-in values before running values tests (#7984) * fix: make the linter coalesce the passed-in values before running values tests Signed-off-by: Matt Butcher <matt.butcher@microsoft.com> * fixed typo Signed-off-by: Matt Butcher <matt.butcher@microsoft.com>

view details

push time in 20 days

delete branch technosophos/k8s-helm

delete branch : fix/7756-linter-values

delete time in 20 days

PR merged helm/helm

feat: make the linter coalesce the passed-in values before running values tests size/L

When support for helm lint --values was added, this support did not extend to the values file tests. This PR extends the support to values files, which lets the user schema-test the combination of the chart and the passed-in values.

Also added tests for other values lints.

Closes #7756

Signed-off-by: Matt Butcher matt.butcher@microsoft.com

+135 -6

2 comments

4 changed files

technosophos

pr closed time in 20 days

issue closedhelm/helm

Helm lint (v3) doesn't take values files into account during schema validation

Edit: Steps to reproduce: https://github.com/helm/helm/issues/7756#issuecomment-617889123

I have a bunch of charts with values.schema.json files that won't pass schema validation without passing in necessary, environment-specific values. I don't want these values in the base values.yaml file because they are environment-specific, but should fail at install/upgrade time.

When running helm lint ${chart} --values ./lint-values.yaml I'm getting errors like below even though these values are provided in ./lint-values.yaml:

==> Linting ${chart}
[ERROR] values.yaml:
- ingress.hosts: Array must have at least 1 items
...

Error: 1 chart(s) linted, 1 chart(s) failed

Important to note that helm template ${chart} --values ./line-values.yaml does not throw any schema validation errors. When I run helm template ${chart} I see the same errors as above:

Error: values don't meet the specifications of the schema(s) in the following chart(s):
agent-services:
- ingress.hosts: Array must have at least 1 items
...

I think this is a bug. helm lint should run values schema validation against the final .Values object like the docs say:

Note that the schema is applied to the final .Values object, and not just to the values.yaml file. This means that the following yaml file is valid, given that the chart is installed with the appropriate --set option shown below.

Source: https://helm.sh/docs/topics/charts/#schema-files


Output of helm version:

version.BuildInfo{Version:"v3.1.1", GitCommit:"afe70585407b420d0097d07b21c47dc511525ac8", GitTreeState:"clean", GoVersion:"go1.13.8"}

Output of kubectl version: not relevant

Cloud Provider/Platform (AKS, GKE, Minikube etc.): not relevant

closed time in 20 days

sean-krail

pull request commenthelm/helm

ref(cmd): prevent klogs flags from polluting the help text

We could add a help message for -v if we really wanted to. I mean, adding just that one might make sense. Most of the flags are just useless for all but dev usage. And they clutter the help text with confusing out-of-context information (like vmodule, whose text makes no sense if you don't know klog).

adamreese

comment created time in a month

pull request commenthelm/helm

ref(cmd): prevent klogs flags from polluting the help text

Yeah, I sometimes see users misunderstanding the -v flag, assuming they are seeing Helm debug info when they are just seeing Klog info.

klooooog

adamreese

comment created time in a month

Pull request review commenthelm/helm

Add checking of length of resourceList before install of uninstall

 func (i *Install) installCRDs(crds []chart.CRD) error { 		} 		totalItems = append(totalItems, res...) 	}-	// Invalidate the local cache, since it will not have the new CRDs-	// present.-	discoveryClient, err := i.cfg.RESTClientGetter.ToDiscoveryClient()-	if err != nil {-		return err-	}-	i.cfg.Log("Clearing discovery cache")-	discoveryClient.Invalidate()-	// Give time for the CRD to be recognized.-	if err := i.cfg.KubeClient.Wait(totalItems, 60*time.Second); err != nil {-		return err+	if len(totalItems) > 0 {

Sounds fine. I'll restate my LGTM for this PR.

waveywaves

comment created time in a month

issue commenthelm/helm

Proposal: Manage CRDs

The problem is simple, and if anyone has a solution, write a proposal and then a PR.

The problem: CRDs are global resources. If a CRD is modified in an incompatible way, it can break all usages of that CRD in the cluster. CRDs are in charts, and it is unreasonable to assume that an operator will read every line of change in a chart. Evidence suggests that it is also unreasonable to assume that chart authors will care enough about installations to prevent compatibility breaks. The consequence of this is that it is likely that updating CRDs will introduce substantial breaking behavior that will impact users beyond just the ones who used the chart.

If anyone can figure out a way to fix this, then please propose it.

But simply saying, "this is the user's problem" doesn't fly. We're the ones who will have to field the issues filed by angry people who accidentally destroy their cluster integrity with a bad upgrade. We're the ones who get at-replied on angry tweet storms. And we're the ones who have to respond to public criticism of the project when someone's chart doesn't do versioning correctly. So please don't tell us that this isn't a valid reason. You're not the ones who will have to deal with the headache.

mattfarina

comment created time in a month

issue commenthelm/helm

Provide an option or alternative for --set and/or --set-string to take a value literally

Update on what? If you want to PR a change, I'm sure it would be welcomed. To my knowledge, nobody is actively working on it. But most likely, you just need to use escape sequences as described above. (Note that in many of these cases, it is the shell that is interpreting characters, not Helm)

maxhov

comment created time in a month

pull request commenthelm/helm

fix: Change early exit condition to accommodate charts with sub dependencies

The issue we are chasing is this: With Helm 3, we assumed (during development) that dependencies would match between Chart.yaml and the directory. But the top level checks were never consistently added. Relaxing the checks will very likely lead to inconsistent behavior. So now we have to figure out what to do.

The two options on the table are to either rewrite the Helm 3 internals to NOT require that the two be in sync, or to make everything stricter.

I am STRONGLY in favor of just make the checks stricter across the board. I don't think there should ever be a case where a chart appears in the charts/ directory but not in the Chart.yaml. I think Helm should produce an error any time it encounters that situation.

However, I'm waiting for other core maintainers to weigh in on a variety of related issues. Then I hope we will come to a uniform view, even if it's not my preferred view.

/cc @mattfarina since we literally talked about this a few hours ago. Also, someone signed up last Helm call to create a meta-issue for this and all related issues. Does anyone remember who signed up? If not, I will start working on it.

smckend

comment created time in a month

Pull request review commenthelm/helm

Add checking of length of resourceList before install of uninstall

 func (i *Install) installCRDs(crds []chart.CRD) error { 		} 		totalItems = append(totalItems, res...) 	}-	// Invalidate the local cache, since it will not have the new CRDs-	// present.-	discoveryClient, err := i.cfg.RESTClientGetter.ToDiscoveryClient()-	if err != nil {-		return err-	}-	i.cfg.Log("Clearing discovery cache")-	discoveryClient.Invalidate()-	// Give time for the CRD to be recognized.-	if err := i.cfg.KubeClient.Wait(totalItems, 60*time.Second); err != nil {-		return err+	if len(totalItems) > 0 {

I do not understand this change. Is this for performance? I am worried that if another process deletes a CRD, the local cache could be outdated here.

waveywaves

comment created time in a month

issue commenthelm/helm

helm lint issue with umbrella chart having templates folder

I did a test with a massive chart with hundreds of subcharts. I changed the tpl function to return an empty string. It cut that chart's helm lint down from 2.5 hours to 2.08 seconds. If you want to test reproducing this, all you have to do is comment out this: https://github.com/helm/helm/blob/master/pkg/engine/engine.go#L127-L152 and then recompile

himmakam

comment created time in a month

pull request commenthelm/helm

Update values.yaml linting to respect value options flags

I explained things in more detail on #7984, but the tl;dr is that the only thing we're really concerned with on this PR is the breaking change to Values().

robbie-demuth

comment created time in a month

Pull request review commenthelm/helm

feat: make the linter coalesce the passed-in values before running values tests

 func All(basedir string, values map[string]interface{}, namespace string, strict  	linter := support.Linter{ChartDir: chartDir} 	rules.Chartfile(&linter)-	rules.Values(&linter)

The issue that was raised with your change (which I hadn't seen until yesterday) was that you changed the public signature of Values(). That is an API breaking change, and is not allowed until Helm 4. @bacongobbler was not blocking your PR based on an abstract notion of "sameness." He was blocking it based on our policy to not introduce breaking changes to the public API. It's true that we do want to make sure things continue to function similarly, but I think you may have gotten sidetracked by that. Fixing a bug is, of course, a proper behavior change. He was just making a sidelong comment that if no values were provided, it should still function the same.

FWIW, I don't have a preference over which our our PRs gets merged. So if you'd rather update yours, I'll review the changes. If I had noticed it before writing this one, I would have offered feedback then instead of doing what equates to duplicate work.

technosophos

comment created time in a month

pull request commenthelm/helm

Update values.yaml linting to respect value options flags

As was pointed out in Feb., this has an API breaking change that needs to be fixed before we can re-review. Is this PR dead or still undergoing work?

robbie-demuth

comment created time in a month

issue closedhelm/helm

[Helm 3] helm package requires argument

<!-- If you need help or think you have found a bug, please help us with your issue by entering the following information (otherwise you can delete this text): -->

According to the description for helm package:

If no path is given, this will look in the present working directory for a Chart.yaml file, and (if found) build the current directory into a chart.

But this is not the case, shown by running helm package:

Error: need at least one argument, the path to the chart

Recommended solution, rather than throwing an error if no args are provided, append to args:

if len(args) == 0 {
  args = append(args, ".")
}

Should be an easy enough PR. 😉 Only one change to the tests should be needed. I don't have golangci-lint, so I couldn't run the tests locally.

Output of helm version:

version.BuildInfo{Version:"v3.0.0", GitCommit:"e29ce2a54e96cd02ccfce88bee4f58bb6e2a28b6", GitTreeState:"clean", GoVersion:"go1.13.4"}

Output of kubectl version: N/A

Cloud Provider/Platform (AKS, GKE, Minikube etc.): N/A

closed time in a month

james-r-smith

issue commenthelm/helm

[Helm 3] helm package requires argument

We are stuck with the current behavior of helm lint until Helm 4 (because of our backward compatibility requirements).

I added #8051 to capture the requirement for Helm 4.

james-r-smith

comment created time in a month

issue openedhelm/helm

proposal: Require a path for 'helm lint'

For a major Helm release, it would be nice to make the following breaking change to helm lint:

Right now, helm lint is the one Helm command that supports an implicit path for ARG1. If helm lint foo is called, Helm will load the chart at foo. But if helm lint is called, it will implicitly call helm lint on the current working directory.

No other Helm commands behave this way, and it can lead to unexpected behaviors in cases like helm lint $mychart (where $mychart is not set).

We should align helm lint with install/upgrade/package/etc. and remove implicit path support.

See #7155

created time in a month

issue commenthelm/helm

version flags is ignored when installing release with "helm upgrade --install"

I am testing on master (3.2+unreleased).

$ helm search repos -l stable/chartmuseum 
NAME              	CHART VERSION	APP VERSION	DESCRIPTION
stable/chartmuseum	2.10.0       	0.12.0     	Host your own Helm Chart Repository
stable/chartmuseum	2.9.0        	0.11.0     	Host your own Helm Chart Repository
stable/chartmuseum	2.8.0        	0.11.0     	Host your own Helm Chart Repository
stable/chartmuseum	2.7.1        	0.11.0     	Host your own Helm Chart Repository
stable/chartmuseum	2.7.0        	0.11.0     	Host your own Helm Chart Repository
stable/chartmuseum	2.6.1        	0.11.0     	Host your own Helm Chart Repository
stable/chartmuseum	2.6.0        	0.11.0     	Host your own Helm Chart Repository
stable/chartmuseum	2.5.0        	0.10.0     	Host your own Helm Chart Repository
stable/chartmuseum	2.4.1        	0.8.2      	Host your own Helm Chart Repository
stable/chartmuseum	2.4.0        	0.8.2      	Host your own Helm Chart Repository
stable/chartmuseum	2.3.3        	0.8.2      	Host your own Helm Chart Repository
... more omitted

Install 2.4.0:

$ helm upgrade --install --version 2.4.0 cm stable/chartmuseum
Release "cm" does not exist. Installing it now.
NAME: cm
LAST DEPLOYED: Mon May  4 14:31:52 2020
NAMESPACE: default
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
** Please be patient while the chart is being deployed **

Get the ChartMuseum URL by running:

  export POD_NAME=$(kubectl get pods --namespace default -l "app=chartmuseum" -l "release=cm" -o jsonpath="{.items[0].metadata.name}")
  echo http://127.0.0.1:8080/
  kubectl port-forward $POD_NAME 8080:8080 --namespace default

Check to make sure 2.4.0 is installed:

$ helm ls
NAME	NAMESPACE	REVISION	UPDATED                            	STATUS  	CHART            	APP VERSION
cm  	default  	1       	2020-05-04 14:31:52.96412 -0600 MDT	deployed	chartmuseum-2.4.0	0.8.2

Use upgrade --install to go to 2.4.1 (still behind the latest):

$ helm upgrade --install --version 2.4.1 cm stable/chartmuseum
Release "cm" has been upgraded. Happy Helming!
NAME: cm
LAST DEPLOYED: Mon May  4 14:36:14 2020
NAMESPACE: default
STATUS: deployed
REVISION: 2
TEST SUITE: None
NOTES:
** Please be patient while the chart is being deployed **

Get the ChartMuseum URL by running:

  export POD_NAME=$(kubectl get pods --namespace default -l "app=chartmuseum" -l "release=cm" -o jsonpath="{.items[0].metadata.name}")
  echo http://127.0.0.1:8080/
  kubectl port-forward $POD_NAME 8080:8080 --namespace default

Check again:

$ helm ls
NAME	NAMESPACE	REVISION	UPDATED                             	STATUS  	CHART            	APP VERSION
cm  	default  	2       	2020-05-04 14:36:14.518717 -0600 MDT	deployed	chartmuseum-2.4.1	0.8.2

I tried the above a few more times, and all seems to work correctly. Can you either try again with Helm 3.2.0 or provide me more info so I can try to reproduce?

arnonki

comment created time in a month

pull request commenthelm/helm

Remove hasAllRepos function

At one point, it was required that all repositories had to be locally pulled before a dependency could be correctly managed. I think this removes one area where that behavior was enforced. I need to take a closer look at the code to see if it is indeed globally optional now (in which case we can merge this PR as-is), or whether there is still a case where this is required.

I suspect that when we added the OCI registry support, we removed the last of the hard dependencies on a local cached copy. But again -- I will verify. It just may take me a while.

kristinnardal2

comment created time in a month

issue closedhelm/helm

lint vs lint --strict confusing

<!-- If you need help or think you have found a bug, please help us with your issue by entering the following information (otherwise you can delete this text): -->

Output of helm version:

2.11.0

I created a chart and wanted to find out if any of my templates were referring to non-existing values (due to typos). So after I created the chart, I purposely created a typo reference via {{ .Values.someMap.doesNotExist and ran helm lint:

helm create test-chart
edit values.yaml etc to create someMap but not someMap.doesNotExist
helm lint 

This showed no error:

==> Linting test-application/
[INFO] Chart.yaml: icon is recommended

1 chart(s) linted, no failures

Then I tried

helm lint --strict  # 

and this failed because nameOverride and fullnameOverride are not defined in the values.yaml, because they are used in the _helpers.tpl:

==> Linting test-application/
[INFO] Chart.yaml: icon is recommended
[ERROR] templates/: render error in "test-application/templates/service.yaml": template: test-application/templates/service.yaml:6:31: executing "test-application/templates/service.yaml" at <include "chart.name"...>: error calling include: template: test-application/templates/_helpers.tpl:6:31: executing "chart.name" at <.Values.nameOverride>: map has no entry for key "nameOverride"

Error: 1 chart(s) linted, 1 chart(s) failed

Then once I define nameOverride and fullnameOverride the above error disappears and finally the missing key that I purposely referenced in the template causes error:

==> Linting test-application/
[INFO] Chart.yaml: icon is recommended
[ERROR] templates/: render error in "test-application/templates/deployment.yaml": template: test-application/templates/deployment.yaml:43:29: executing "test-application/templates/deployment.yaml" at <.Values.http.apiUrl2>: map has no entry for key "apiUrl2"

Frankly this is a bit of a mess:

  • firstly there should at least be a warning if keys are not defined, even without strict
  • secondly, it doesn't make sense that strict causes failure on the nameOverride and fullnameOverride because there was no warning on those without strict mode
  • nameOverride and fullnameOverride should only be needed if the chart name is not defined, therefore they should not cause error even in strict mode since the chart name is defined

I think this behavior is confusing. When I lint source code, I expect that potential problems are warned, and errors show up as errors, and that strict mode would cause warnings to be interpreted as errors. New errors can appear, but not of the sort that should have been warnings (missing keys).

closed time in a month

schollii

issue commenthelm/helm

lint vs lint --strict confusing

This has been changed in Helm 3, but we do not plan on porting the feature to Helm 2 (which is now in bugfix-only mode). I am marking this as closed.

schollii

comment created time in a month

issue closedhelm/helm

helm lint documentation misleading

Output of helm version:

$ helm version --client
Client: &version.Version{SemVer:"v2.12.3", GitCommit:"eecf22f77df5f65c823aacd2dbd30ae6c65f186e", GitTreeState:"clean"}

helm lint --help shows this documentation:

      --strict                   fail on lint warnings

However, this seems wrong. When I run helm lint ..., I get no output. When I run with helm lint --strict ... I get error messages.

My expectation is that I get warnings, an that if I enable --strict those result in an exit code of 1. But the warnings should always show up!.

Demo with https://github.com/istio/installer:

$ helm lint istio-control/istio-discovery -f global.yaml
==> Linting istio-control/istio-discovery
Lint OK

1 chart(s) linted, no failures
$ helm lint istio-control/istio-discovery -f global.yaml --strict
==> Linting istio-control/istio-discovery
[ERROR] templates/: render error in "istio-discovery/templates/deployment.yaml": template: istio-discovery/templates/deployment.yaml:15:32: executing "istio-discovery/templates/deployment.yaml" at <include (print $.Tem...>: error calling include: template: istio-discovery/templates/configmap.yaml:52:18: executing "istio-discovery/templates/configmap.yaml" at <.Values.pilot.authPo...>: map has no entry for key "authPolicy"

Error: 1 chart(s) linted, 1 chart(s) failed

closed time in a month

howardjohn

issue commenthelm/helm

helm lint documentation misleading

Closed by #8017

howardjohn

comment created time in a month

push eventtechnosophos/k8s-helm

Matt Butcher

commit sha 08e546f169ff3d5694863f0766c3132da2f095b7

fix: removed strict template errors in linter (#8017) Signed-off-by: Matt Butcher <matt.butcher@microsoft.com>

view details

Matt Butcher

commit sha b6a3b5fa9399a81af7d373dbcfe63ff9270d02c0

feat: lint info on template spacing failure Signed-off-by: Matt Butcher <matt.butcher@microsoft.com>

view details

Matt Butcher

commit sha 43e48c75c7dc92b23c02414c2529a837daba863d

ignore template comments, fix bad test data Signed-off-by: Matt Butcher <matt.butcher@microsoft.com>

view details

Matt Butcher

commit sha 4904cfc6788f1da5c6c86df72b152d25c7906961

fixed a few newly merged templates that have spacing errors Signed-off-by: Matt Butcher <matt.butcher@microsoft.com>

view details

push time in a month

delete branch technosophos/k8s-helm

delete branch : fix/7483-strict-template-values

delete time in a month

push eventhelm/helm

Matt Butcher

commit sha 08e546f169ff3d5694863f0766c3132da2f095b7

fix: removed strict template errors in linter (#8017) Signed-off-by: Matt Butcher <matt.butcher@microsoft.com>

view details

push time in a month

PR merged helm/helm

fix: removed strict template errors in linter bug size/M

<!-- Thanks for sending a pull request! Here are some tips for you:

  1. Make sure to read the Contributing Guide before submitting your PR: https://github.com/helm/helm/blob/master/CONTRIBUTING.md
  2. If this PR closes another issue, add 'closes #<issue number>' somewhere in the PR summary. GitHub will automatically close that issue when this PR gets merged. Alternatively, adding 'refs #<issue number>' will not close the issue, but help provide the reviewer more context.-->

What this PR does / why we need it:

This PR closes #7483 by no longer setting the Engine.Strict flag on the template engine when helm lint --strict is executed.

According to the documentation for --strict, when it is specified, it converts warnings to errors. However, in the code, --strict=true also sets the template engine into Strict. When the template engine is in strict mode, if any value is missing from the .Values object, it produces an error. However, templates frequently use things like {{ default "foo" .Values.optionalThing }} to allow users to override a default. In this case, it is likely that a value will not be present in the Values.yaml.

Issue #7483 reports this as a bug. I think it is open to interpretation. So I have opened a PR that changes the behavior, but we could certainly decide not to change this particular behavior.

Special notes for your reviewer:

If we merge this PR, some charts that did not pass helm lint --strict will now pass.

If applicable:

  • [ ] this PR contains documentation
  • [X] this PR contains unit tests
  • [X] this PR has been tested for backwards compatibility

Closes #7483

Signed-off-by: Matt Butcher matt.butcher@microsoft.com

+52 -1

5 comments

2 changed files

technosophos

pr closed time in a month

issue closedhelm/helm

Helm3: lint --strict broken for "default" on maps

Output of helm version: version.BuildInfo{Version:"v3.0.2", GitCommit:"19e47ee3283ae98139d98460de796c1be1e3975f", GitTreeState:"clean", GoVersion:"go1.13.5"}

Given the following values:

myMap:
  key1: value1

And the following expressions:

{{ default "default1" .Values.myMap.key1 }}
{{ default "default2" .Values.myMap.key2 }}

Renders to

value1
default2

helm lint is fine with that expressions. Nevertheless, helm lint --strict fails with

[ERROR] templates/: template: [templatename].yaml:5:29: executing "[templatename].yaml" at <.Values.myMap.key2>: map has no entry for key "key2"

closed time in a month

micw

pull request commenthelm/helm

fix: removed strict template errors in linter

Given that this PR resolves five bugs, I am going to merge it and assume that the expected behavior is NOT to change the template rendering engine.

technosophos

comment created time in a month

push eventtechnosophos/k8s-helm

liuming216448

commit sha cca68288063d235a4c32ef1ba822dd487317c8dc

fix: allow to rollback to previous version even if no deployed releases(#6978) Signed-off-by: liuming <hit_oak_tree@126.com>

view details

liuming

commit sha e7adc4b5d73ec76a84a5e8ae258823b3d2990a74

Merge remote-tracking branch 'helm/master'

view details

liuming

commit sha 299ccd9e8878e6194d9d2a19affd4fbe0ee65f38

Merge remote-tracking branch 'helm/master'

view details

Liu Ming

commit sha fe308142956d1641d614a7414f5d9b6717f2a1e7

Merge remote-tracking branch 'helm/master'

view details

Liu Ming

commit sha 98ec2760c800ddcd75d27c75318cd979fb1c6a39

Merge remote-tracking branch 'helm/master'

view details

Liu Ming

commit sha bd08203a0fc742d3abebcc333f17968239be5cbb

Merge remote-tracking branch 'helm/master'

view details

Liu Ming

commit sha 376a5ca55074ffa339faa40cdecca246404056ea

Merge remote-tracking branch 'helm/master'

view details

Liu Ming

commit sha a1685b737dd6846bdc35c281bf841b9cc43cb104

Merge remote-tracking branch 'helm/master' Signed-off-by: Liu Ming <hit_oak_tree@126.com>

view details

Liu Ming

commit sha b99d493a9e1bce54d4ff61d90d67a9221906bbfc

Merge remote-tracking branch 'helm/master'

view details

Liu Ming

commit sha 48ac9ee390deaa9a9a17ea599ea12309c0d93866

Merge remote-tracking branch 'helm/master'

view details

Liu Ming

commit sha ee91c3e85fead414d89fb6ec1399dc7bda828df2

Merge remote-tracking branch 'helm/master'

view details

Liu Ming

commit sha 7ffdfa45e3b5e224293d65cd6267f8aa1f18bff9

Merge remote-tracking branch 'helm/master'

view details

Liu Ming

commit sha 029922202a1875a0328b2757e30536e46c946a03

Merge remote-tracking branch 'helm/master'

view details

Lüchinger Dominic

commit sha fb829c2c843df01ad1dd5ffd13c4e923be4ab9e9

Fix markdown table in helm command doc The tables aren't rendered correctly because the syntax was wrong. Fixed it by applying the https://www.markdownguide.org/extended-syntax/#tables table syntax. See https://helm.sh/docs/helm/helm/#synopsis for the wrong rendering. ![Broken table in html](https://imgur.com/bniKxO6) Fix for helm/helm-www#575 Signed-off-by: Lüchinger Dominic <dev@snowgarden.ch>

view details

Liu Ming

commit sha 84288701b36e42b1d64873e804ddf4c584717f5d

Merge remote-tracking branch 'helm/master'

view details

Martin Hickey

commit sha 72a1e9afa30f07f9e40582967c69a70c16862512

Merge pull request #8025 from dol/fix/docu-helm-root-table Fix markdown table in helm command doc

view details

Liu Ming

commit sha 9be54fa3cec40fb2953f2b665ca775e98e911497

Merge remote-tracking branch 'helm/master'

view details

Liu Ming

commit sha ff3ed53b7c0c07aab2bc8cc59344d18063e8a719

polish to keep the same log style Signed-off-by: Liu Ming <hit_oak_tree@126.com>

view details

Martin Hickey

commit sha c0edc586c55d57bc4a288a17c628ca943e1d5ef1

Merge pull request #8034 from liuming-dev/master polish to keep the same log style

view details

Matt Butcher

commit sha bf9d629dc02e759a1ba09ff8f6784dd0fb585cf3

feat: implement deprecation warnings in helm lint (#7986) * feat: implement deprecation warnings in helm lint Signed-off-by: Matt Butcher <matt.butcher@microsoft.com> * added more deprecated APIs Signed-off-by: Matt Butcher <matt.butcher@microsoft.com>

view details

push time in a month

issue closedhelm/helm

helm lint is missing `--version`

helm package supports setting a chart's version via the --version flag. This is useful when the version is managed by a different tool such as make, maven/gradle etc. as it allows omitting the version in Chart.yaml and setting it when packaging the chart.

helm lint should be consistent and support setting a version on the command line as well. Instead, it gives the following error when trying to lint a chart without version:

$ helm lint .    
==> Linting .
[ERROR] Chart.yaml: version is required

Output of helm version: Client: &version.Version{SemVer:"v2.11.0", GitCommit:"2e55dbe1fdb5fdb96b75ff144a339489417b146b", GitTreeState:"clean"}

closed time in a month

s-spindler

issue commenthelm/helm

helm lint is missing `--version`

I worked on this for a while, and have come to the conclusion that it is outside of the scope of the linter to be able to rewrite parts of the chart before testing. I just can't find a compelling reason to say that in this case it makes sense to test the linter, but modify the input data of the linter. It doesn't match the philosophy we have taken with values, and there are no other places where we allow the linter to overwrite parts of the chart.

I think it is completely reasonable to say that fields must all be set prior to beginning the linting process.

Furthermore, this is not a "consistency with helm package" issue. helm package is a write operation that writes as output a chart. The linter is a read-only operation. While I can appreciate that it might make a CI pipeline slightly easier, I don't think that is a good enough reason to make this deep of a modification to the linter.

I'm am closing this with "wont fix"

s-spindler

comment created time in a month

issue commenthelm/helm

helm lint is missing `--version`

I am going to give this a quick try as the last of my 3.3 Helm lint fixes.

s-spindler

comment created time in a month

issue commenthelm/helm

helm lint is missing `--version`

Anyone interested in taking this on for Helm 3?

s-spindler

comment created time in a month

pull request commenthelm/helm

fix: removed strict template errors in linter

Closes #5417 for Helm 3 (without going the opposite route suggested in that PR)

technosophos

comment created time in a month

issue closedhelm/helm

test before install/upgrade?

I'm curious if there is a pattern similar to helm test that allows you to run a short lived pod before commiting to a helm install. Perhaps use a temporary namespace with the deployment resources swapped out for short lived pod resources? One hacky way to accomplish this might be to have two charts, a "real chart" and a chart that would be deleted after it returned an exit code.

Let me know if what I am asking even makes sense. Thanks.

Example CICD pipeline with pretest

Test

  • helm lint
  • make test

Build

  • docker build ... && docker push ...

Integration Test

  • docker run image echo "test"
  • helm pretest

Deploy

  • helm upgrade --install ...

closed time in a month

marshallford

issue commenthelm/helm

test before install/upgrade?

Closing as wont fix, as this has seen a year of inactivity and nobody has put together a complete proposal.

marshallford

comment created time in a month

push eventtechnosophos/k8s-helm

Matt Butcher

commit sha 63942943ba2e956cf439d4ab5394d7ef1a84c8ba

ignore template comments, fix bad test data Signed-off-by: Matt Butcher <matt.butcher@microsoft.com>

view details

push time in a month

issue closedhelm/helm

Helm lint does not warn or error on duplicate keys at the same level of config

<!-- If you need help or think you have found a bug, please help us with your issue by entering the following information (otherwise you can delete this text): -->

Output of helm version:

Client: &version.Version{SemVer:"v2.12.1", GitCommit:"02a47c7249b1fc6d8fd3b94e6b4babf9d818144e", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.12.1", GitCommit:"02a47c7249b1fc6d8fd3b94e6b4babf9d818144e", GitTreeState:"clean"}

Output of kubectl version:

Client Version: version.Info{Major:"1", Minor:"13", GitVersion:"v1.13.1", GitCommit:"eec55b9ba98609a46fee712359c7b5b365bdd920", GitTreeState:"clean", BuildDate:"2018-12-13T10:39:04Z", GoVersion:"go1.11.2", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"10", GitVersion:"v1.10.11", GitCommit:"637c7e288581ee40ab4ca210618a89a555b6e7e9", GitTreeState:"clean", BuildDate:"2018-11-26T14:25:46Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"linux/amd64"}

Cloud Provider/Platform (AKS, GKE, Minikube etc.): in-house kubernetes

closed time in a month

bigjonroberts

issue commenthelm/helm

Helm lint does not warn or error on duplicate keys at the same level of config

I am marking this as "won't fix", as it appears that this is largely a feature of all of the YAML processors I have tested. The spec actually doesn't give any meaningful guidance on parsing in this situation -- only that a YAML serializer should not emit duplicate keys. The template engine in Helm is not a YAML serializer, per se. It is a text template engine. And the parser/serializer in Helm does indeed seem to follow the specification.

If someone wanted to fix this, it appears that they would have to write a custom YAML stream parser and emit errors. We have talked in the past about writing a custom YAML parser for Helm and decided conclusively that we will not do that. It's simply not a code weight that it makes sense for Helm to include.

bigjonroberts

comment created time in a month

issue commenthelm/helm

feat: Global `helmignore` file

Re-titled this to reflect the current state.

igor-karpukhin

comment created time in a month

more