2018/03/02 14:34:33 warn: charts.yaml is loaded: charts.yaml is deprecated in favor of helmfile.yaml. See #25 for more information
2018/03/02 14:34:33 err: open helmfile.yaml: no such file or directory

Extracted from #60 (comment)

I would be interested in getting helmfile integrated with the helm-secrets project. From looking at it, it might be possible to just change the helm binary that is called to the helm-secrets wrapper with a command line flag.

https://github.com/futuresimple/helm-secrets

How are others handling secrets?

Hi,
It isn't clear how can put the values files inside source control (e.g. GIT). The best option will be allowing additional option in charts.yaml:

valueRepositories:
  - name: values
    url: http://roboll.io/values

Thanks

Hi,

first of all: Awesome idea and library. Thank you.

Many tools and libraries use yml as a file suffix for YAML files. I intuitively created a file called charts.yml.
Do you think you can support both file suffixes: yaml and yml?

Extracted from #60 (comment)

TL;DR; Not specifying --reset-values while calling out helm upgrade --install in the context of Helmfile seems completely wrong to me right now.

Can we just force it?

Would there be any appetite to allow inlining values in their natural nested form (instead of name/value pair). I imagine it would require temporary file creation during execution, unless there are libs to convert nested yaml to json dot notation. Not sure if that is beyond helmfile's remit.

eg:

charts:
  - name: vault                      
    namespace: vault             
    chart: roboll/vault-secret-manager
    inlined_values: 
      some:
        quite:
        - name: deep
          value: 
            variable: {{ env "VAL" }}

Using Helm CLI shows that one Helm release can include several Helm charts - one main chart and several subcharts. Am I missing something or should charts.yaml therefore be releases.yaml?

Example:

Generic chart: rails-app
Unique releases: dev-example-com, prod-example-com, dev-example-org, prod-example-org

Workflow:

1. Create a generic Helm chart with some default values.yaml
2. Add one or more releases, each with its own unique values.yaml

One cluster, many charts, more releases 🤔

“Helm deployment” here should be “Helm release” also. “Deployment” is a very specific Kubernetes term, and not a Helm term at all.

Am I wrong?

There is a subtle issue with Helmfile when:

• The -f flag is used to reference a file outside of the current working directory
• The Helmfile manifest uses relative file paths to reference the charts

What Helmfile is currently doing in this case is resolving those relative file paths to against the PWD and not against the Helmfile's directory.

We use Helmfile and love the simplicity of managing the manifests at this level.

One reality we have is that people at times make manual changes to the infrastructure and charts change over time. We would love the ability to be able to run something like helm diff with the context of the helmfile as a way of indicating the changes that would be made.

Specifically being able to understand the impact of a given PR in our CI/CD system would be really wonderful.

helmfile validate

Examines helmfiles for possible issues.

Synopsis

The command validates the syntax of the default or specified helmfile(s) and runs a series of tests to verify that they are well-formed.

If the linter encounters things that will cause the chart to fail installation, it will emit [ERROR] messages. If it encounters issues that break with convention or recommendation, it will emit [WARNING] messages (linting).

The following could be reported:

• invalid YAML syntax
• wrong format namespace value, chart names, versions, env var declarations, repository URLs, ..
• same release, value fileor repository declared multiple times
• interpolation used in places where it's unsupported
• missing value for a variable (if enabled)

helm validate [flags]

Suggested Options

      --strict               Fail on lint warnings
      --file valueFiles      Specify helmfile (can specify multiple) (default `helmfile.yaml`)
      --follow-values        check syntax of specified values files
      -e, --env              Set environment variables
      --env-file             Read in a file of environment variables
      --check-variables=true Check whether all required variables have been specified. (default `true`)

Reference

Inspired by helm lint, terraform validate and docker run.

The PR #78 adds env variable interpolation to repository URLs, but I forgot to add a relevant section in the Readme and/or an example.

For security reason as noted in the last sentence of #36, probably after #78 is merged.

How about enable masking when and only when {{ env ... }} template referenced env vars with secret-ish name, for example *_TOKEN, *_SECRET and/or *_KEY?

Maybe use goreleaser in the CI to do so?

I can make a PR, but can a maintainer help by adding the githb auth token and getting it working?

I've started using helmfile, and after a couple of days of use, I am missing a way to do helm dependency update. Should it be a part of helmfile? And included in sync

Just a note to add test -z "$(find . -path ./vendor -prune -type f -o -name '*.go' -exec gofmt -d {} + | tee /dev/stderr)" to make check.

Currently, helmfile delete runs helm delete --purge. This might be unexpected for helm users. Shouldn't purge be an optional flag?

Alternatively, we could have two actual commands for convenience and to make it crystal clear:

helmfile delete
helmfile purge

I'm a bit hesitant to propose this but how about supporting oneshot jobs in helmfile?

An oneshot job can be either a K8S job or a pod created via helm upgrade --install to accomplish a job like db migration, enqueueing a large job to a kind of workflow system, etc.

As of today, we have to resort a variant of kubectl run --image $img to run an oneshot job, even in a situation that our regular app are managed by helm and shared the image, envvars with oneshot jobs.

AFAIK, there's no such tool to support this use-case. And supporting it in helmfile allows us to provide a more docker-compose-like U/X to helm users, but the docker-build feature.

Thoughts?

cc/ @roboll @sstarcher

Extracted from #60 (comment)

Please see the discussion made there for more context.

When there is an error, one has to parse through the entire output to find out what went wrong. A summary of releases and their status (or even abbreviated error message) would help to quickly identify the problem.

We would like to deploy the same group of charts to the same cluster in different namespaces (branch environments)

Would there be any desire to see that in helmfile? eg --kube-namespace

We should add a couple of new-lines to improve readability of the output. It's difficult to parse the output quickly:

• where does one release end and another start
• what's helmfile output and helm output

In the case of an error, the error message is printed without any indication of the affected release. For example, in the middle of two successful releases, I found the following error for third one. But I had to manually go through the helmfile to find out which one it might have been.

Error: UPGRADE FAILED: failed to create patch: failed to get versionedObject: unable to convert unstructured object to apps/v1beta1, Kind=StatefulSet: cannot restore struct from: string

I've started using helmfile, and after a couple of days of use, I am missing a way to do helm status on the repo's that the helmfile points to..

The help text for the charts command currently is:

helm repo upgrade --install

Shouldn't it be:

helm upgrade --install

Hi there,

I just wanted to rewrite this piece of working code:

helm install stable/prometheus --name prom --set rbac.create=false --namespace=prometheus

my simple helmfile:

vim charts.yaml
 
...
context:  <my_context>
releases:
  # Published chart example
  - name: prometheusnorbac                            # name of this release
    namespace: prometheus                       # target namespace
    chart: stable/prometheus     # the chart being installed to create this release, referenced by `repository/chart` syntax
    set:                                   # values (--set)
      - name: rbac.create
        value: false
...
wq!

When I run:

./helmfile -f charts.yaml sync
exec: helm repo update
Hang tight while we grab the latest from your chart repositories...
...Skip local chart repository
...Successfully got an update from the "stable" chart repository
Update Complete. ⎈ Happy Helming!⎈

Then chcek helm list

 helm list
NAME            REVISION        UPDATED                         STATUS          CHART                   NAMESPACE
prom            1               Thu Mar 15 14:22:19 2018        DEPLOYED        prometheus-5.4.3        prometheus
promt           1               Fri Mar 16 11:50:31 2018        FAILED          prometheus-5.4.3        prometheus
promtemp        1               Fri Mar 16 10:58:31 2018        DEPLOYED        prometheus-5.4.3        prometheus

So from helm list output can be seen that deployment for prometheusnorbac was never finished.

Tested OS's

• Ubuntu 16.04.4 LTS
• Centos 7.3

fatal error: concurrent map writes

goroutine 6 [running]:
runtime.throw(0x11c4712, 0x15)
/usr/local/Cellar/go/1.9.4/libexec/src/runtime/panic.go:605 +0x95 fp=0xc420043908 sp=0xc4200438e8 pc=0x10292f5
runtime.mapassign_faststr(0x1194640, 0xc420078510, 0x11c2e6b, 0xe, 0x12d3980)
/usr/local/Cellar/go/1.9.4/libexec/src/runtime/hashmap_fast.go:861 +0x4da fp=0xc420043988 sp=0xc420043908 pc=0x100c5ba
text/template.(*Template).associate(0xc420056140, 0xc420056140, 0xc4200ce100, 0xe, 0x1, 0x2)
/usr/local/Cellar/go/1.9.4/libexec/src/text/template/template.go:224 +0xad fp=0xc4200439c8 sp=0xc420043988 pc=0x10ff96d
text/template.(*Template).AddParseTree(0xc420056140, 0x11c2e6b, 0xe, 0xc4200ce100, 0x0, 0x0, 0x0)
/usr/local/Cellar/go/1.9.4/libexec/src/text/template/template.go:128 +0x11c fp=0xc420043a30 sp=0xc4200439c8 pc=0x10fe8cc
text/template.(*Template).Parse(0xc420056140, 0xc420010340, 0x34, 0x10d1eaf, 0xc420048de0, 0x2)
/usr/local/Cellar/go/1.9.4/libexec/src/text/template/template.go:205 +0x20a fp=0xc420043b40 sp=0xc420043a30 pc=0x10ff64a
github.com/roboll/helmfile/state.renderTemplateString(0xc420010340, 0x34, 0x2, 0xc420010340, 0x34, 0x0)
/Users/sstarcher/go/src/github.com/roboll/helmfile/state/state.go:87 +0x45 fp=0xc420043b98 sp=0xc420043b40 pc=0x1148845
github.com/roboll/helmfile/state.flagsForChart(0xc42001a240, 0x22, 0xc420043f50, 0x0, 0x0, 0x0, 0x0, 0x0)
/Users/sstarcher/go/src/github.com/roboll/helmfile/state/state.go:246 +0x274 fp=0xc420043e10 sp=0xc420043b98 pc=0x11498f4
github.com/roboll/helmfile/state.(*HelmState).DiffCharts.func1(0xc420082500, 0xc42000adc0, 0x12d3218, 0x0, 0x0, 0x12a1820, 0xc420056980, 0xc4200165c0, 0xc420016410, 0xe, ...)
/Users/sstarcher/go/src/github.com/roboll/helmfile/state/state.go:171 +0x71 fp=0xc420043f10 sp=0xc420043e10 pc=0x114b371
runtime.goexit()
/usr/local/Cellar/go/1.9.4/libexec/src/runtime/asm_amd64.s:2337 +0x1 fp=0xc420043f18 sp=0xc420043f10 pc=0x1055841
created by github.com/roboll/helmfile/state.(*HelmState).DiffCharts
/Users/sstarcher/go/src/github.com/roboll/helmfile/state/state.go:168 +0x1e4

goroutine 1 [semacquire]:
sync.runtime_Semacquire(0xc4200165cc)
/usr/local/Cellar/go/1.9.4/libexec/src/runtime/sema.go:56 +0x39
sync.(*WaitGroup).Wait(0xc4200165c0)
/usr/local/Cellar/go/1.9.4/libexec/src/sync/waitgroup.go:131 +0x72
github.com/roboll/helmfile/state.(*HelmState).DiffCharts(0xc420082500, 0x12a1820, 0xc420056980, 0x12d3218, 0x0, 0x0, 0x60000000008, 0x18, 0x18)
/Users/sstarcher/go/src/github.com/roboll/helmfile/state/state.go:190 +0x239
main.main.func3(0xc42009a280, 0x0, 0x0)
/Users/sstarcher/go/src/github.com/roboll/helmfile/main.go:150 +0x17f
reflect.Value.call(0x118c9c0, 0x11cc568, 0x13, 0x11c12b8, 0x4, 0xc420043778, 0x1, 0x1, 0xc4200436f8, 0x11b8e20, ...)
/usr/local/Cellar/go/1.9.4/libexec/src/reflect/value.go:434 +0x905
reflect.Value.Call(0x118c9c0, 0x11cc568, 0x13, 0xc420043778, 0x1, 0x1, 0xc42009a280, 0x1319988, 0x0)
/usr/local/Cellar/go/1.9.4/libexec/src/reflect/value.go:302 +0xa4
github.com/roboll/helmfile/vendor/github.com/urfave/cli.HandleAction(0x118c9c0, 0x11cc568, 0xc42009a280, 0x0, 0x0)
/Users/sstarcher/go/src/github.com/roboll/helmfile/vendor/github.com/urfave/cli/app.go:483 +0x180
github.com/roboll/helmfile/vendor/github.com/urfave/cli.Command.Run(0x11c133c, 0x4, 0x0, 0x0, 0x0, 0x0, 0x0, 0x11caf4b, 0x33, 0x0, ...)
/Users/sstarcher/go/src/github.com/roboll/helmfile/vendor/github.com/urfave/cli/command.go:186 +0x9ed
github.com/roboll/helmfile/vendor/github.com/urfave/cli.(*App).Run(0xc420001080, 0xc42000a060, 0x2, 0x2, 0x0, 0x0)
/Users/sstarcher/go/src/github.com/roboll/helmfile/vendor/github.com/urfave/cli/app.go:237 +0x57d
main.main()
/Users/sstarcher/go/src/github.com/roboll/helmfile/main.go:212 +0x9ea

goroutine 5 [runnable]:
text/template.(*Template).Execute(0xc420056140, 0x129f340, 0xc420100000, 0x0, 0x0, 0x0, 0x2)
/usr/local/Cellar/go/1.9.4/libexec/src/text/template/exec.go:179 +0x76
github.com/roboll/helmfile/state.renderTemplateString(0xc4200d0000, 0x39, 0x2, 0xc4200d0000, 0x39, 0x0)
/Users/sstarcher/go/src/github.com/roboll/helmfile/state/state.go:93 +0xad
github.com/roboll/helmfile/state.flagsForChart(0xc42001a240, 0x22, 0xc420077f50, 0x0, 0x0, 0x0, 0x0, 0x0)
/Users/sstarcher/go/src/github.com/roboll/helmfile/state/state.go:246 +0x274
github.com/roboll/helmfile/state.(*HelmState).DiffCharts.func1(0xc420082500, 0xc42000adc0, 0x12d3218, 0x0, 0x0, 0x12a1820, 0xc420056980, 0xc4200165c0, 0xc420018440, 0x13, ...)
/Users/sstarcher/go/src/github.com/roboll/helmfile/state/state.go:171 +0x71
created by github.com/roboll/helmfile/state.(*HelmState).DiffCharts
/Users/sstarcher/go/src/github.com/roboll/helmfile/state/state.go:168 +0x1e4

goroutine 7 [runnable]:
text/template/parse.(*lexer).emit(0xc4200ca180, 0x6)
/usr/local/Cellar/go/1.9.4/libexec/src/text/template/parse/lex.go:156 +0xc5
text/template/parse.lexText(0xc4200ca180, 0x6)
/usr/local/Cellar/go/1.9.4/libexec/src/text/template/parse/lex.go:269 +0x1e0
text/template/parse.(*lexer).run(0xc4200ca180)
/usr/local/Cellar/go/1.9.4/libexec/src/text/template/parse/lex.go:231 +0x5f
created by text/template/parse.lex
/usr/local/Cellar/go/1.9.4/libexec/src/text/template/parse/lex.go:224 +0x15f

goroutine 17 [runnable]:
runtime.goexit1()
/usr/local/Cellar/go/1.9.4/libexec/src/runtime/proc.go:2365 +0x4e
runtime.goexit()
/usr/local/Cellar/go/1.9.4/libexec/src/runtime/asm_amd64.s:2338 +0x6
created by text/template/parse.lex
/usr/local/Cellar/go/1.9.4/libexec/src/text/template/parse/lex.go:224 +0x15f

I really like the idea of this tool, but it would be important to know under which license it is running, in order to safely make it part of a workflow. Is it MIT? Currently, it seems like no license (https://choosealicense.com/no-license/) ..

Why are those releases not readily installable on osx? What extra step is needed to consume those files?

Running helmfile sync, helmfile delete and then helmfile sync again results in helm/helm#3208.
More concretely, you get something like:

$ PROJECT=deis/empty-testbed ENV=staging IMAGE=mumoshu/golang-k8s-aws:1.9.1 COMMAND='go' SERVICE_ACCOUNT=default helmfile sync
exec: helm repo add brigade https://azure.github.io/brigade
"brigade" has been added to your repositories
exec: helm repo update
Hang tight while we grab the latest from your chart repositories...
...Skip local chart repository
...Successfully got an update from the "incubator" chart repository
...Successfully got an update from the "kubeherd" chart repository
...Successfully got an update from the "es-operator" chart repository
...Successfully got an update from the "brigade" chart repository
...Successfully got an update from the "stable" chart repository
Update Complete. ⎈ Happy Helming!⎈
exec: helm upgrade --install brigade-project brigade/brigade-project --values myvalues.yaml --set secrets.env=staging,secrets.image=mumoshu/golang-k8s-aws:1.9.1,secrets.command=go,secrets.serviceAccount=default,project=deis/empty-testbed,repository=github.com/deis/empty-testbed,cloneURL=https://github.com/deis/empty-testbed.git
WARNING: Namespace doesn't match with previous. Release will be deployed to kube-system
Error: UPGRADE FAILED: "brigade-project" has no deployed releases
err: exit status 1

This seems to prevent us from just re-running helmfile sync without changing charts[].name in charts.yaml each time you run helmfile delete.

Would it be better for helmfile to just purge releases so that we don't need to change charts[].name so often?

Hi, maybe adding a requirements property to each chart section could tell helmfile to install dependencies first? Is that an idea? Is there a way to know if dependencies are ready?

Extracted from #49 (comment)

This still seems like a scope-creep regarding what helmfile do today, yet I find nowhere to do this cleanly outside of helmfile.

Similar to the one for kubernetes-on-aws.

It will help users and maintainers have another aspect of confidence in their project and tooling, while allowing maintainers to try to contact prod users in case it seems necessary(like before making a breaking change, scope-creep, etc.

we're using a private chart repo with token auth in github: see https://medium.com/@kavehmz/using-a-private-github-repo-as-helm-chart-repo-https-access-95629b2af27c

and when trying to switch from a large umbrellla chart to use helmfile, running into an issue that the chart can't be found

here's a sample of the helmfile:

repositories:
  - name: authtest
    url: https://[email protected]/org/helmrepo/master/stable

charts:
  - name: dev-service
    namespace: dev
    chart: authtest/service
    # version: 1.1.1
    values:
    - service-values.yaml # (relative path to manifest)

and the output of helmfile -f charts.yaml sync:

exec: helm repo add authtest https://[email protected]/org/helmrepo/master/stable
"authtest" has been added to your repositories
exec: helm repo update
Hang tight while we grab the latest from your chart repositories...
...Skip local chart repository
...Successfully got an update from the "authtest" chart repository
...Successfully got an update from the "roboll" chart repository
...Successfully got an update from the "stable" chart repository
Update Complete. ⎈ Happy Helming!⎈
exec: helm upgrade --install dev-service authtest/service --namespace dev --values .../service-values.yaml
Error: file "authtest/service" not found
err: exit status 1```

To simplify building a hierarchy of values files "outside" of the helmfile, it would be useful for deduplication to specify a set of default files to always load. On top of that, the key-value map of the releases could be made available for interpolation:

...

defaults:
  values:
      - "./values/all/traefik.yaml"
      - "./values/{{ release.name }}/traefik.yaml"

releases:
  - name: traefik
    namespace: platform
    chart: stable/traefik
    version: 1.24.1

What do you guys think about this?

Would it be possible to enhance the env var interpolation feature, so that we could safely git-commit a helmfile referencing private chart repositories which requires authn?

For example, we can use private git repos as helm chart repos like described in https://github.com/kmzfs/helm-repo-in-github#how-to-use-it-as-a-helm-repo.
However, it requires you to include a sensitive information(=auth credential) in repository urls.

Simply doing it results in a charts.yaml like:

respositories:
- name: your-private-git-repo-hosted-charts
  url: https://[email protected]/kmzfs/helm-repo-in-github/master/

which ins't very good to be committed into your git repo.

If the repositories section had a support for env var interpolation, it would look like:

respositories:
- name: your-private-git-repo-hosted-charts
  url: "https://{{ env \"GITHUB_TOKEN\"}}@raw.githubusercontent.com/kmzfs/helm-repo-in-github/master/"

This makes helmfile safe enough to be committed into a git repo.

Note that running helm sync would result in printing the repository url containing the token like:

exec: helm repo add your-private-git-repo-hosted-charts https://[email protected]/kmzfs/helm-repo-in-github/master/

I'd like to fix it, too. However, it could be done in an another github issue.

I have a loop that runs helmfile diff 100 times. Sometimes the following value will output true, but the majority of the time it has the correct value

      - name: config.s3.bucket
        value: '{{ env "S3_BUCKET" }}'

• exec: helm diff chart chart config.s3.bucket=true
• exec: helm diff chart chart config.s3.bucket=bucket-name

While trying to modularize our deployment slightly, we broke out our Helmfile into two different sets which we had residing in the same directory.

Attempting to use the -f command with the helmfile repos command, we receive an error around the flag not being defined properly

Is it possible to install a specific version of a chart?

Hi,

just stumbled over this tool and could not image how to live without it! Idea is brilliant as it is simple. Thanks for that. :)

I was just wondering, if there is an argument which limits the list of charts to work on by some kind of expression. Its not always desired to iterate across the whole list of charts. Nevertheless its easily possible to write just a charts.yaml which lists only the desired charts, but this is some kind of cumbersome.

Image something like that: helmfile charts --limit "metrics*" which just works on the charts where the given glob pattern match against.

Thoughts on allowing version constraints to be specified.

• Currently we support version and when not specified it will install the latest version
• Support for semver range constraints to allow users to say ~2.2.0 to get the latest version of the 2.2.x

I really want to use 1 charts.yaml file for my project. But I want to be able to control the charts separate as well..

Would a tagging system be a good idea?

Example charts.yaml:

charts:
  - name: a1
    chart: ../charts/c1/
    tags:
      - tag1
  - name: a2
    chart: ../charts/c1/
    tags:
      - tag1
      - tag2
  - name: b1
    chart: ../charts/c1/
    tags:
      - tag3
  - name: c1
    chart: ../charts/c1/

Then helmfile could be used like:

# sync a1, a2
helmfile --tags tag1 sync

# sync a1, a2, b1
helmfile --tags tag1,tag3 sync

# sync all
helmfile sync

As seen in #55 (comment)

We should add a validation for releases[].chart!

When I try to run helmfile -f charts.yml diff or helmfile -f charts.yml diff --sync-repos it fails as follows:

exec: helm diff mq-demo reg-stage/rabbitmq
exec: helm diff terminator local/terminator
Error: file "local/terminator" not found
Error: plugin "diff" exited with error
Error: file "reg-stage/rabbitmq" not found
Error: plugin "diff" exited with error
err: exit status 1
err: exit status 1

with the helmfile:

repositories:
  - name: local                         
    url: http://127.0.0.1:8879/charts
  - name: reg-stage
    url: <another-url>

charts:
  - name: terminator                     # helm deployment name
    chart: local/terminator              # chart reference
  - name: mq-demo
    chart: reg-stage/rabbitmq

Am I doing something wrong or is this a bug?

It would be awesome if Helmfile could cause Charts.yml to interpolate environment variables.

I currently have my project's deployment in a chart directory in my repo. I pass environment variables in via set:

helm upgrade my-project-$NODE_ENV ./kubernetes/my-project/ \
     --set namespace=$NODE_ENV \
     --set web.imageName=$WEB_NAME \
     --set api.imageName=$API_NAME \
     --set env.dockerRepoUrl=$DOCKER_REPO_PREFIX \
     --set env.dockerImageTag=$DOCKER_REPO_TAG \
     --set env.hostname=$NODE_ENV.$KUBERNETES_HOST \
     --install --debug

This is just about the only imperative part of my build step. I'd love to move it into the Helmfile format, but it'd be nice not to have to add a step to run my Helmfile through envsubst.

What do you think of the idea of Helmfile doing environment variable substitution on its own?

Use Case: In my CI flow I have multiple helm repositories to install (initially 3, will be more). I initialize helm and then add the repositories with: helmfile repos. However, I'm seeing most of the time only 1 or 2 of the repositories show up on subsequent helmfile charts or using helm repo list.

I don't see any additional arguments to helmfile I need to make this work or anything I'm doing incorrectly. Please let me know if I'm missing something. See #46 for exact steps to test/reproduce.

Background: it appears this is because the calls to helm repo add are done asynchronously and helm doesn't fully support it. I am running on 3 node kubernetes cluster with kubernetes 1.9.3 with latest versions of helm/helmfile (info below).

What I've tried: I've tried this test case with both the released helmfile (https://github.com/roboll/helmfile/releases/tag/v0.8) and latest master and it has the same issue. I also have tried with the latest release of helm (https://github.com/kubernetes/helm/releases/tag/v2.8.1) as well as the latest version of master (helm/helm@b49a396 - March 5th). I though this bug (helm/helm#3253) in helm around client concurrency might fix the issue with helm, however it did not fix the issue even when I ran with helm from master. That said, even if there was a fix in helm master for this, I think helmfile should strongly consider not requiring the absolute latest version of helm.

Potential Fix: I've created a potential fix in a pull request (#46) which just makes the calls to helm repo add synchronous. This is slightly slower, but the calls to helm repo add are pretty fast and having them reliably work is more important than a fraction of a second.

I have quite a large helmfile and helm (or tiller) is starting to time out when deploying to my local cluster in minikube. Would it be possible to have an argument to limit the number of concurrent requests being made to helm at a time. Maybe something like --max-connections=X, if unset you could leave it as unlimited, but if set helmfile should only make at most X requests at a time.

Usecase

I'm creating a small chart with out StorageClass configuration, but there's already one present with the same name, so I'd like helm to "take it under its wings". This can be done by running helm install --replace. However, this goes against the idempotent way of running helm upgrade --install that we do when we run the charts or sync action.

Proposal

Could we:

• Mark releases to be "replaceable" so we check whether it's run for the first time and we do a install instead of an upgrade?
• Also, provide a way to pass arguments to helm on a release level, so we could pass --replace directly in the state file (now I have to do it on the command-line and it's valid for all releases, so I have to use the label selector).

The --kube-context CLI flag does not do anything. Passing in different contexts simply uses the default context. Even passing in a bad context name uses the default. The preview execution that is printed out is clearly not what is actually running.

Example command that will use default context:

$ helmfile --kube-context BAD_CONTEXT_NAME sync
exec: helm upgrade --install test stable/datadog --kube-context BAD_CONTEXT
...

When run manually, helm is able to accept context and apply just like helmfile should:

helm upgrade --install test stable/datadog --kube-context staging --file test.yaml

As you can see helm errors out if passed in a bad context:

$ helm list --kube-context BAD_CONTEXT_NAME
Error: could not get kubernetes config for context 'BAD_CONTEXT_NAME': context "BAD_CONTEXT_NAME" does not exist