v0.3.8

Commands Affected

• tls gen
• helm wait-for-tiller [NEW]

Description

This release updates the tls gen command to use the new way of authenticating to Kubernetes (specifically passing in server and token info directly) and using JSON to configure the TLS subject.

This release also introduces a new command helm wait-for-tiller which can be used to wait for a tiller deployment to roll out Pods, and have at least one Pod that can be pinged. This enables chaining calls to helm after helm is deployed when using a different helm deployment process that doesn't rely on the helm client (e.g creating deployment resources manually).

Reference

• #44

v0.3.7

Commands Affected

• k8s wait-for-ingress [NEW]

Description

This release introduces the k8s wait-for-ingress sub command which can be used to wait until an Ingress resource has an endpoint associated with it.

Reference

• #43

v0.3.6

Description

All commands that setup TLS certificates (e.g helm deploy and helm grant) can now take in the TLS subject information as a json.

Reference

• #40

v0.3.5

Description

All commands that need to authenticate to Kubernetes (e.g eks deploy, helm deploy, etc) now take in direct authentication parameters as an alternative means to auth. You can now pass in the authentication parameters --kubectl-server-endpoint, --kubectl-certificate-authority and --kubectl-token to the command to setup authentication to the Kubernetes cluster, as opposed to setting up the config.

Reference

• #38
• #39

v0.3.4

Commands Affected

• eks token

Description

The eks token command now accepts a new parameter --as-tf-data, which will encode the token output in a format that can be used as an external data source in terraform. This allows you to configure the kubernetes and helm providers without configuring a kubectl context.

Reference

• #37

v0.3.3

Commands Affected

• tls gen [NEW]

Description

This release introduces the tls gen sub command which can be used to generate TLS certificate key pairs that are managed using Kubernetes Secrets.

Reference

• #34
• #35

v0.3.2

Commands Affected

• helm deploy

Description

This release fixes the following bugs:

• helm deploy was not able to successfully authenticate against a GKE cluster on Google Cloud Platform.

Additional improvements:

• Updated the Gopkg.lock file.

Reference

• #25
• #29
• #32

v0.3.1

Commands Affected

• helm deploy
• helm configure

Description

This release introduces the following new feature:

• You can now specify the Tiller container image to use with helm deploy, using the --tiller-image and --tiller-version flags.

This release fixes the following bugs:

• helm deploy had a bug where the client was configured after Tiller was confirmed to be deployed. However, the Tiller deployment check requires connecting to Tiller, leading to a chicken and egg problem. This fixes that by delaying the polling step until after the client has been granted access and configured.
• helm configure did not setup the helm home directory with the initial set of repository, leading the operator to run the repo update command immediately after configuring. This fixes that by installing the stable repo as part of configure.
• helm deploy required finding the executable kubergrunt in the PATH, exactly as is. This removes that need.

Additional improvements:

• helm deploy now uses the helm go library instead of calling out to the helm client.

Reference

• #21
• #22
• #23

v0.3.0

Commands Affected

• helm deploy [BREAKING CHANGE]

Description

This release fixes two bugs:

• helm deploy had a bug where the client certificates were generated using the same parameters as the server certificates. Fixing this requires new required parameters to the command: --client-tls-common-name and --client-tls-org.
• helm deploy had a bug where it ignored the --helm-home directory when deploying Tiller. This prevented a custom home directory from being initialized.

Reference

• #16
• #17

v0.2.0

Commands Affected

• helm deploy [BREAKING CHANGE]

Description

This release updates the helm deploy command to now require an RBAC entity to be passed in (one of --rbac-user, --rbac-group, or --rbac-service-account), which will be used to configure the local helm client.

This ensures that you can interact with helm immediately after a deploy, without the need to grant and configure.

Reference

• #14