praqma / helmsman

Helm Charts as Code

Helmsman v3.0.0 works only with Helm versions >=3.0.0. For older Helm versions, use Helmsman v1.x

What is Helmsman?

Helmsman is a Helm Charts (k8s applications) as Code tool which allows you to automate the deployment/management of your Helm charts from version controlled code.

How does it work?

Helmsman uses a simple declarative TOML file to allow you to describe a desired state for your k8s applications as in the example toml file. Alternatively YAML declaration is also acceptable example yaml file.

The desired state file (DSF) follows the desired state specification.

Helmsman sees what you desire, validates that your desire makes sense (e.g. that the charts you desire are available in the repos you defined), compares it with the current state of Helm and figures out what to do to make your desire come true.

To plan without executing:

helmsman -f example.toml

To plan and execute the plan:

helmsman --apply -f example.toml

To show debugging details:

helmsman --debug --apply -f example.toml

To run a dry-run:

helmsman --debug --dry-run -f example.toml

To limit execution to specific application:

helmsman --debug --dry-run --target artifactory -f example.toml

Features

• Built for CD: Helmsman can be used as a docker image or a binary.
• Applications as code: describe your desired applications and manage them from a single version-controlled declarative file.
• Suitable for Multitenant Clusters: deploy Tiller in different namespaces with service accounts and TLS (versions 1.x).
• Easy to use: deep knowledge of Helm CLI and Kubectl is NOT mandatory to use Helmsman.
• Plan, View, apply: you can run Helmsman to generate and view a plan with/without executing it.
• Portable: Helmsman can be used to manage charts deployments on any k8s cluster.
• Protect Namespaces/Releases: you can define certain namespaces/releases to be protected against accidental human mistakes.
• Define the order of managing releases: you can define the priorities at which releases are managed by helmsman (useful for dependencies).
• Parallelise: Releases with the same priority can be executed in parallel.
• Idempotency: As long your desired state file does not change, you can execute Helmsman several times and get the same result.
• Continue from failures: In the case of partial deployment due to a specific chart deployment failure, fix your helm chart and execute Helmsman again without needing to rollback the partial successes first.

Install

From binary

Please make sure the following are installed prior to using helmsman as a binary (the docker image contains all of them):

• kubectl
• helm (helm >=v2.10.0 for helmsman >= 1.6.0, helm >=v3.0.0 for helmsman >=v3.0.0)
• helm-diff (helmsman >= 1.6.0)

If you use private helm repos, you will need either helm-gcs or helm-s3 plugin or you can use basic auth to authenticate to your repos. See the docs for details.

Check the releases page for the different versions.

# on Linux
curl -L https://github.com/Praqma/helmsman/releases/download/v3.17.0/helmsman_3.17.0_linux_amd64.tar.gz | tar zx
# on MacOS
curl -L https://github.com/Praqma/helmsman/releases/download/v3.17.0/helmsman_3.17.0_darwin_amd64.tar.gz | tar zx

mv helmsman /usr/local/bin/helmsman

As a docker image

Check the images on dockerhub

As a package

Helmsman has been packaged in Archlinux under helmsman-bin for the latest binary release, and helmsman-git for master.

You can also install Helmsman using Homebrew

brew install helmsman

As an asdf-vm plugin

asdf plugin-add helmsman
asdf install helmsman latest

Documentation

Documentation for Helmsman v1.x can be found at: docs v1.x

• How-Tos.
• Desired state specification.
• CMD reference

Usage

Helmsman can be used in three different settings:

• As a binary with a hosted cluster.
• As a docker image in a CI system or local machine Always use a tagged docker image from dockerhub as the latest image can (at times) be unstable.
• As a docker image inside a k8s cluster

Contributing

Pull requests, feedback/feature requests are welcome. Please check our contribution guide.

helmsman's Issues

add functional tests

non existing releases fail when checking if they are protected.

If a release does not already exist, the release protection check fails with a panic error.

This bug affects v1.0.0 only.

configure a CI pipeline on circleci

Add slack notifications from Helmsman

Allow helmsman to send slack notifications using an incoming webhook.
Notifications should include error messages -in cases of failures- and a summary of the generated plan of action -in case of success-.

When applying actions, each action in the plan (install/delete/upgrade/rollback) should have a notification sent to indicate it's finished successfully.

Setting up ~/.kube/config should be separated from helmsman

had great trouble (last night) getting a simple/example mysql deploy to work because ~/.kube/config was setup on my local machine using gcloud --jason method, and I could not replicate that setup using helmsman and circleci. Currently helmsman uses a combination of certificates and usernames and password passed to it through circleci env variable, which does not allow it to work with my use-case.
In short, I see that there are many ways to configure ~/.kube/config , and not all use the regular options of certificates and usernames and passwords. e.g. helmsman is built on alpine image, which does not contain gcloud commands. So even if I can magically copy the exact .kube/config from my computer into the helmsman container, it still fails as gcloud command is hard-coded in the .kube/config file when this file is created using gcloud auth --json=file method.

I suggest that we move the ~/.kube/config setup part out of helmsman completely and let something else take care of it. Helmsman should expect it to work before it starts to deploy helm charts on the cluster.

Allow to set values in DSF

I notice that currently, the .set node supports overriding properties defined in the values files, but using only environment variables as values. I`d like to propose that values should not be limited to environment variables. It seems like there are only a few lines of code that would be affected:

• helmsman/release.go

  Line 56 in 4c7dd44

  return false, "the value for variable [ " + k + " ] must be an environment variable name and start with '$'."

  : this would probably be replaced with only a check that if something starts with a $, then the env var must exist.

• helmsman/decision_maker.go

  Line 285 in 10f3c65

  for k, v := range r.Set {

  : this would check that if values starts with a $ sign, then assume the rest is an env var value (get it as code does now etc), else the values is given verbatim to the command (not sure if it would need quotes added).
• there might be tests to fix

I could try to do this if you`re in favor of this feature, but it might be faster for you to do it, not sure.

release validation does not validate app details correctly in v1.4.0-rc

support a bit better variable munging

My golang isn't good enough to pull this off but I see that variable substitution is limited to the names of variables but no string interpolation.

This means that a desirable behavior like appName = "MySimpleApp.$fqdn" can't happen, even though it seems like a natural pattern since appName = "$HOSTNAME" can because the code finds the leading $ and looks up the environment variable.

I'd like to propose the normal pattern of STRING-$VARIABLENAME-STRING where the code would understand that any patterns of letters after a $ is a variable name.

support TLS

as described in #22

Attempting to create a context when username and password are not provided in the desired state file.

Behaviour:

the following settings table in the desired state file:

...
[settings]
kubeContext = "clusterX" 

...

leads to helmsman trying to create a new context clusterX when it does not already exist.

Expected behaviour:
to fail and say that it can not create the context since credentials are not provided in settings.

Difference between helmsman and helmfile

How does helmsman differentiate itself versus helmfile?

Both try to solve managing multiple helm applications from a single configuration file.

Create new namespace instead of moving into

Sometimes I just want to deploy into a new namespace to test some things. If I did a deployment, then update the DSF with a new namespace, then try helmsman --apply DSF again, helmsman will attempt to move the existing services to this new namespace. In my case, that's not what I want, it should just create the new namespace and deploy into it. I cannot find a way of preventing helmsman from doing this.

It is also not clear to me how it figures out what the previous namespace was, the docs say there is no cached info. I tried usin ns-override, and using a different filename for DSF, no luck, always helmsman say that it will move the service from one namespace to the new, and protection just causes helmsman to say that nothing can be done because origin ns is protected, must remove protection first.

Any suggestions?

Update: I can see from

helmsman/decision_maker.go

Line 24 in 10f3c65

func decide(r *release, s *state) {

that there is not likely a way around that without code changes.

support rolling back to a specific release revision

as of v0.1.2, rolling back is by default done to the latest revision. Need to support rolling back to an earlier revision.

allow releases with same name to be deployed through multiple Tillers.

This only applies to clusters with multiple Tillers (in different namespaces). It is legal (by helm) to use the same release name with different Tillers.

Currently, helmsman rejects duplicate release names when validating a desired state file. The validation need to be changed to check release name uniqueness within individual Tillers only.

upgrade failed releases instead of delete and reinstall

in the case of a release becoming in the failed state, Helmsman currently delete and reinstall it which is not good for production apps .. need to do an upgrade instead

build docker image with all dependencies

Helmsman docker image should contain helm, kubectl, helm s3 plugin and helmsman.

Add possibility to install chart using tiller from different namespace

This is useful if there is more granularity of namespaces.

Example:
Namespaces:

production-frontend
production-backend
production-tools

staging-frontend
staging-backend
staging-tools
...

Tiller is only installed in production-tools or equivalent environment: staging-tools, testing-tools, etc..

BUG/How-To: Use helmsman with only RBAC for a given namespace

I want a desired state file for each namespace, allowing each team to own a namespace and run helmsman for it.

Given a service account dev which is a ClusterAdmin for a given namespace, helmsman returns the following error:

namespaces:
  custom-ns:
    protected: false
    installTiller: true
    tillerServiceAccount: tiller

2018/08/06 12:00:27 ERROR: while deploying Helm Tiller in namespace [kube-system]: Error: error installing: deployments.extensions is forbidden: User "system:serviceaccount:custom-ns:dev" cannot create deployments.extensions in the namespace "kube-system": Unknown user "system:serviceaccount:custom-ns:dev"

If I add the kube-system details to my desired state file, I get the following error instead:

namespaces:
  kube-system:
    protected: false
    installTiller: true # or false
    tillerServiceAccount: tiller

2018/08/06 12:04:46 ERROR: while deploying Helm Tiller in namespace [kube-system]: Error from server (Forbidden): serviceaccounts "tiller" is forbidden: User "system:serviceaccount:custom-ns:dev" cannot get serviceaccounts in the namespace "kube-system": Unknown user "system:serviceaccount:custom-ns:dev"

Pre-installing the tiller service account in the custom namespace is not a problem, but why does helmsman need to connect to kube-system and how/can I operate it without?

Support local charts on file system

According to the desired state docs (for the chart field) it must contain repo and chart.
I would like to be able to deploy a chart from the local file system as well.

Example:

apps:
  jenkins:
    name: "mychart
    description: "My Local Chart
    namespace: "staging"
    enabled: true
    chart: "./mychart"

support a way to authenticate with private S3 Helm chart repos

need to support expressing S3 private helm repos in the desired state file and use that repo by using the Helm S3 plugin.

Add possibility to specify multiple yaml files with values

This is something helm supports. It can be used to have common file for some app, and dedicated files for each environment (staging/prod).

Check that Tiller service accounts exist in namespaces where Tiller is going to be installed.

this is related to #43

helmsman checks if the default Tiller service account exists in the namespace before it initializes helm in kube-system. But for other namespaces, it attempts to initialize helm without validating first that the specified service account exists. This leads to a timeout while waiting for Tiller to become ready in those namespaces.

Add possibility to specify desired state file as YAML

yaml has become popular in kubernetes ecosystem. It has also many out-of-the-box tools to validate syntax during CI/CD pipeline

How to improve run time on larger desired state files?

First, thank you for sharing helmsman with the community. When I kicked the tires on it using a smallish toml configuration with 2 apps, performance of a full run took a handful of seconds. Everything was good. But now, with ~30 helm charts defined and installed in a 10-node cluster, a CI run takes well over 8 minutes. For bumping, say, a container version in a values.yaml for one app, this greatly slows iteration speed. It appears to be ever-growing problem with regard to how many calls to helm there are and the increased time each helm call takes. The logs show quite a few helm calls per chart, and each one takes 4 seconds to return.

$ time helm ls
...snip...
30 helm charts installed
...snip...
real	0m3.897s
user	0m0.173s
sys	0m0.070s

Also, with so many long runs, there is now a much higher likelihood of a race condition between multiple overlapping CI runs even 2+ minutes apart. helmsman seems to gather its state in the beginning and then implement the work, so the second CI job will notice a chart is not there and then later go to implement it, only to error out because the first CI run placed it there in the meantime.

Any ideas/strategies for improving overall performance of each run? I'd love to see things get under a minute, if possible. Thanks!

allow upgrading a release with a newly passed values.yaml if the release is already deployed.

this would make any changes to values.yaml take effect even if the release is already deployed and no other changes are required to the release.

support reading password for cluster connection from an environment variable.

Currently, a .passwd file is needed to contain the password. This file should be excluded from version control (using .gitignore).

This method does not work when running helmsman in a container in CI pipeline. Therefore, it should be replaced to read the password from an environment variable.

Local paths should be relative to manifest file

Having this directory structure

.
├── k8s
│   ├── helmsman.yaml
│   └── values
│       └── nginx-ingress.yaml

if I run this command from . directory

helmsman -f k8s/helmsman.yaml

I need to put this to helmsman.yaml:

  nginxIngress:
    valuesFile: ./k8s/values/nginx-ingress.yaml

but it should be

  nginxIngress:
    valuesFile: ./values/nginx-ingress.yaml

so that relative paths are consistent regardless of what directory helmsman is called from.

More detailed docs

Hi, I would like to know more about what are the internal flows of helmsman. Do you have some design docs ?

charts with "-" in their name get unnecessarily reinstalled.

a chart like "kubernetes-dashboard" are continuously detected as changing their namespaces:

DECISION: release [ kubernetes-dashboard ] is desired to use a new Chart [ stable/kubernetes-dashboard ]. I am planning a purge delete of the current release and will install it with the new chart in namespace [[ kube-system ]]

More helm default overrides

Currently, helmsman allows overriding of a few helm defaults, such as adding the "wait" flag on a given app.

It would be useful to have most or all of the command-line options of helm represented in helmsman, so it is possible to do things like extend the timeout (--timeout flag).

handle set values containing special characters.

The following example demonstrates this bug:

export PASSWORD="b79nz,[email protected],col'.;llney.5.jkhkjhiuhn!vhj"

...
desired_state_file.toml
-------
[apps.demo]
    name = "demo" # should be unique across all apps
    description = "demo"
    namespace = "staging" 
    enabled = true 
    chart = "demo/demo-chart" 
    version = "0.2.0"
    valuesFile = ""
    [apps.demo.set]
    "DB.USER"="myuser"
  "DB.PASSWORD"="$PASSWORD"

Currently, the string for DB.PASSWORD is not quoted before passing. This sometimes break the chart installation at run time.
Additionally, the , is treated as a separator. So the above DB.PASSWORD will be interpreted at runtime as

DB:
    PASSWORD: b79nz
xyz: 
    864t@c: ochjguygkney
... 

All commas in the set values must be escaped and the value string must be quoted.

support passing secrets to charts through env variables.

Using the --set helm flag, secrets can be passed to helm charts when they are installed/upgraded from env variables (defined in CI ).

For this, the desired state file need to include definition of the env vars to be used and the decision maker should process these vars.

Output some notes like Helm does for charts

When you run helm install, it outputs the contents of Notes.txt for the chart. This is handy to explain how to test the chart. Similarly, there should be a way to specify notes when helmsman --apply is run. Outputting the individual chart notes may not be very useful, because the notes you would want would be for the "group" of charts deployed. For example, a good place to add notes about testing that the deployed services are reachable.

So I imagine a Notes file specific to each namespace (since if I am not mistaken, all apps items in the TOML file that match a certain namespace get installed) in the same folder as the toml. It could similarly be parameterized so that the output contains actual values taken from the various values files and toml.

Create the necessary RBAC service accounts for deploying Tiller if they don't already exist.

this is related to #43

It makes sense that helmsman creates the necessary service account for deploying Tiller if they don't exist.

add setup for helm and kubectl to connect to a cluster at runtime.

Sensible default values for settings

Use this config:

apps:
  nginx-ingress-ext:
    description:  enable nginx ingress controller
    namespace:    kube-system
    chart:        stable/nginx-ingress
    version:      0.22.1

Expected result:

• That stable/nginx-ingress is deployed as nginx-ingress-ext in the namespace kube-system.

Actual result:

• an error is issued that the name is required (proposal: fallback to nginx-ingress-ext as parent key name, which is what I think most people would expect)
• if you add the name, it is not deployed (proposal: default to enabled: true which is IMO the more common scenario

TOML parser and Go disagree on the stringyness of strings

./helmsman -f ./healthcare.toml --debug
 _          _
| |        | |
| |__   ___| |_ __ ___  ___ _ __ ___   __ _ _ __
| '_ \ / _ \ | '_ ` _ \/ __| '_ ` _ \ / _` | '_ \
| | | |  __/ | | | | | \__ \ | | | | | (_| | | | |
|_| |_|\___|_|_| |_| |_|___/_| |_| |_|\__,_|_| |_|version: v1.2.0-rc2
A Helm-Charts-as-Code tool.


2018/05/23 14:58:36 INFO: validating that helm is installed.
2018/05/23 14:58:37 INFO: validating that kubectl is installed.
2018/05/23 14:58:37 toml: cannot load TOML value of type bool into a Go string

It's entirely possible I'm abusing the .set tag in toml. My code looks like:

[settings]
kubeContext = "somecontext"

[namespaces]
[namespaces.monitoring]
protected = false

[helmRepos]
stable = "https://kubernetes-charts.storage.googleapis.com"
incubator = "http://storage.googleapis.com/kubernetes-charts-incubator"

[apps]
  [apps.prometheus]
    name = "prometheus-hc-01"
    description = "prometheus"
    namespace = "monitoring"
    enabled = true
    chart = "stable/prometheus"
    version = "6.7.0"
    # valuesfile = "/path/to/values"
    purge = false
    test = true
    #
    [apps.prometheus-hc-01.set]
      "alertmanager.ingress.enabled" = true
      "alertmanager.ingress.annotations.external-dns\u002Ealpha\u002Ekubernetes\u002Eio/hostname" = "prometheus-alertmanager.$AWS_DEFAULT_REGION.$KUBE_DOMAIN"
      "alertmanager.ingress.annotations.kubernetes\u002Eio/ingress.class" = "nginx"
      "alertmanager.ingress.annotations.kubernetes\u002Eio/tls-acme" = true
      "alertmanager.ingress.hosts[0]" = "prometheus-alertmanager.$AWS_DEFAULT_REGION.$KUBE_DOMAIN"
      "alertmanager.ingress.tls[0].secretName" = "kubernetes-prometheus-alertmanager-tls"
      "alertmanager.ingress.tls[0].hosts[0]" = "prometheus-alertmanager.$AWS_DEFAULT_REGION.$KUBE_DOMAIN"

And another issue is the tags being named like external-dns.alpha.kubernetes.io which probably isn't something --set isn't going to like but that's not related to this project.

Add support for helm-secrets

Currently, helmsman supports passing secrets via environment variables. It would be helpful to allow secrets in a helmsman configuration through the use of the helm-secrets plugin: https://github.com/futuresimple/helm-secrets

Helmfile (a similar project) offers this capability already: https://github.com/roboll/helmfile

provide a way to run kubectl apply to configure additional things after helm is run

The scenario is something like the letsencrypt helm chart which installs on it's own but then requires additional hints normally applied with kubectl -f somestuff.yaml. Basically giving helmsman the ability to workaround issues like this where the entire configuration isn't available in the helm chart itself.

support reading certificates for cluster connection from S3 buckets.

use S3 buckets to read certificates instead of having file paths which require mounting volumes to the helmsman container.

Upgrades fail when using kube-system Tiller

Found what seems to be an easily reproducible bug:

1. Install a release with helmsman using only the kube-system Tiller (no per-namespace Tillers)
2. Update the version number for an app in the helmsman configuration
3. Apply helmsman configuration again

Two things happen: the release is found to not exist, because helmReleaseExists checks for [release]-[tiller-namespace], when it should actually look for [release]-[installed-namespace]; so it attempts a new installation, which fails because the release is already present. It fails to do a proper upgrade check and then upgrade the release.

Long arg names should require double dash

Only single-letter command line arg names should have a single dash; arg names with more than one letter, like debug and apply, should use double-dash, as is conventional in unix systems.

create contribution guide

Better documentation for installTiller=true

So far we have been using helmsman with tiller installed by default in kube-system. There are a couple of namespaces which should have their own tiller, so I'm trying to use installTiller=true for those, but I see this:

Helmsman version: v1.2.0-rc2-060518
2018/06/18 19:34:27 INFO: validating that helm is installed.
2018/06/18 19:34:29 INFO: validating that kubectl is installed.
2018/06/18 19:34:30 INFO: Parsed [[ /project/helmsman.toml ]] successfully and found [ 6 ] apps.
2018/06/18 19:34:30 INFO: namespace validation -- Tiller is desired to be deployed WITHOUT TLS in namespace [ myns ]. 
2018/06/18 19:34:30 INFO: setting kubectl context to [ my-context ]
2018/06/18 19:34:30 VERBOSE: kubectl config use-context my-context
2018/06/18 19:34:30 INFO: creating namespace  myns
2018/06/18 19:34:30 VERBOSE: kubectl create namespace myns
2018/06/18 19:34:31 WARN: I could not create namespace [myns ]. It already exists. I am skipping this.
2018/06/18 19:34:31 INFO: validating that serviceaccount [ tiller ] exists in namespace [ kube-system ].
2018/06/18 19:34:31 VERBOSE: kubectl get serviceaccount tiller -n kube-system
2018/06/18 19:34:32 INFO: deploying shared Tiller on namespace [ kube-system ].
2018/06/18 19:34:32 INFO: initializing helm on the current context and upgrading Tiller on namespace [ kube-system ].
2018/06/18 19:34:32 VERBOSE: helm init --upgrade --service-account tiller --tiller-namespace kube-system --override 'spec.template.spec.containers[0].command'='{/tiller,--storage=secret}'
2018/06/18 19:34:35 INFO: deploying Tiller on namespace [ myns ].
2018/06/18 19:34:35 INFO: initializing helm on the current context and upgrading Tiller on namespace [ myns ].
2018/06/18 19:34:35 VERBOSE: helm init --upgrade --service-account tiller --tiller-namespace myns --override 'spec.template.spec.containers[0].command'='{/tiller,--storage=secret}'
2018/06/18 19:34:36 INFO: checking if helm Tiller is ready in namespace [ myns ].
2018/06/18 19:34:36 VERBOSE: helm list --tiller-namespace myns
2018/06/18 19:34:36 INFO: waiting for helm Tiller to be ready ...
2018/06/18 19:34:41 INFO: checking if helm Tiller is ready in namespace [ myns ].
2018/06/18 19:34:41 VERBOSE: helm list --tiller-namespace myns
2018/06/18 19:34:42 INFO: waiting for helm Tiller to be ready ...
2018/06/18 19:34:47 INFO: checking if helm Tiller is ready in namespace [ myns ].
2018/06/18 19:34:47 VERBOSE: helm list --tiller-namespace myns
<... keeps doing this until it eventually gives up...>

It seems to me that I need to setup RBAC for myns, as described in https://github.com/kubernetes/helm/blob/master/docs/rbac.md? If that is correct, there probably should be a reference to this in https://github.com/Praqma/helmsman/blob/master/docs/how_to/multitenant_clusters_guide.md, perhaps a short explanation of why this is not handled automatically by helmsman.

add unit tests

Enable defining protected namespaces/applications

We need to enable users to define a set of namespaces/applications as desired to be protectedto avoid messing up a production deployment. This can be added to the desired state declarative file

For that we need a definition of protected. I suggest the following:

1. Apps/Services (Helm releases) that are under protection CANNOT be deleted, upgraded or moved to other namespaces.
2. Apps/Services CAN be moved into protection from a non-protected state.
3. If a protected app/service need to be updated/changed or even deleted, this is possible .. but the protection has to be removed first (i.e. remove the namespace/app from the protected state).

The advantage of this feature is: if you are managing production and non-production apps/services in the same cluster (using different namespaces) from a single desired state file, then messing up a production system becomes harder as it requires two steps: a) remove the protection b) do something crazy.

We can define protection at one of two levels:

1. At the namespace level: protection applies to any application in a protected namespace.
2. At the application level: each application definition can have a protected flag.

I am leaning towards the namespace level protection. It is a cleaner way as the protected namespaces will defined in their separate TOML table (section) in the desired state file. It also means making mistakes requires at least two edits in two different locations of the file which reduces the chances of accidental mistakes causing damage.

The protection feature will be optional. And we would still encourage users to maintain separate environments wherever possible and use different desired state files for different environments.

@meekrosoft @KamranAzeem any thoughts on the protection definition and the approach to enforce it?

testing executing a plan fails inside a container.

allow certificates to be used from local file system.

It is useful for testing purposes to be able to specify certs as relative paths from local file system in the desired state file.

Use --purge when deleting charts

Steps to reproduce

1. install a chart (using helm from the command line)
2. add the chart's config into a helmsman file, set enabled: false (or omit it, currently)
3. run helmsman -apply (the chart should be deleted, see appendix I below)
4. add enabled: true to the chart
5. run run helmsman -apply again

Expected result::

The chart should be re-deployed

Actual result:

An error message (see Appendix II below) with a weird "exit code" character. Might be my fonts are not configured, but I guess there should be a number ... :)

Steps to manually fix this:

helm delete --purge nginx-ingress-ext. After that a re-run of helmsman -apply just works.

Metadata

• Helmsman version: 1.3.0-rc1

Appendix I

The deletion of the chart by helmsman:

2018/07/12 13:45:25 INFO: Plan generated at: Thu Jul 12 2018 13:45:25 
DECISION: release [ nginx-ingress-ext ] is desired to be deleted . Planing this for you! -- priority: 0
2018/07/12 13:45:25 INFO: sorting the commands in the plan based on priorities (order flags) ... 
2018/07/12 13:45:25 INFO: Executing the following plan ... 
----------------------
2018/07/12 13:45:25 INFO: Plan generated at: Thu Jul 12 2018 13:45:25 
DECISION: release [ nginx-ingress-ext ] is desired to be deleted . Planing this for you! -- priority: 0

Appendix II

The error message:

2018/07/12 13:46:16 INFO: Plan generated at: Thu Jul 12 2018 13:46:15 
DECISION: release [ nginx-ingress-ext ] is currently deleted and is desired to be rolledback to namespace [[ kube-system ]] . It will also be upgraded in case values have changed. -- priority: 0
2018/07/12 13:46:16 INFO: sorting the commands in the plan based on priorities (order flags) ... 
2018/07/12 13:46:16 INFO: Executing the following plan ... 
----------------------
2018/07/12 13:46:16 INFO: Plan generated at: Thu Jul 12 2018 13:46:15 
DECISION: release [ nginx-ingress-ext ] is currently deleted and is desired to be rolledback to namespace [[ kube-system ]] . It will also be upgraded in case values have changed. -- priority: 0
2018/07/12 13:46:17 Command returned with exit code: �. And error message: Error: "nginx-ingress-ext" has no deployed releases

update documentation for v0.1.2