Embed Helm to change ordering of polling #21
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Motivation
When testing
kubergrunt
on EKS, I ran into a bug where the--wait
parameter ofhelm init
causes trouble. When working off of a clean helm home directory, it appears that in order to poll for Tiller,helm
requires the working TLS configuration to exist and so it fails the polling step of the deploy.I still don't know why this works fine in
minikube
.Solution
The solution implemented here is to break the polling step to be after the local client is configured. Since we require an RBAC entity to be passed during the deploy, it is guaranteed that we will always setup a new local helm client, so we can push the polling to be after this step.
However, in order to do this, we need more control over the deployment process. As such, I decided to embed helm into
kubergrunt
so we can call out to the underlying library functions. Unfortunately, much of it was hidden in private functions so I had to copy paste them here (FWIW,terraform-helm-provider
does similar things).Additional Notes
kubernetes
libraries don't implementdep
. As a result, there is some hard coded dependency overrides in here that were discovered through dependency grunt work, manually going throughGodeps.json
andglide.lock
files.undeploy
). As a result, we still need the helm client to be installed. I punted on the work to adaptundeploy
for now, since I think getting a deployable service helm chart is higher priority.helm repo update
after configure in order to actually use the client to install stuff.