Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added output for generated kubeconfig filename #272

Merged
merged 2 commits into from
Feb 18, 2019

Conversation

syst0m
Copy link
Contributor

@syst0m syst0m commented Feb 7, 2019

PR o'clock

Description

The terraform helm provider uses a kubectl config filename as a config parameter.
The eks module generates a kubectl config with a random filename.
In order to enable integration between the two and facilitate automated provisioning of an eks cluster,
by passing the kubectl config filename as an input
to the terraform helm provider, I added a new output to the eks module.

terraform helm provider: https://github.com/terraform-providers/terraform-provider-helm

Checklist

  • terraform fmt and terraform validate both work from the root and examples/eks_test_fixture directories (look in CI for an example)
  • Tests for the changes have been added and passing (for bug fixes/features)
  • Test results are pasted in this PR (in lieu of CI)
  • I've added my change to CHANGELOG.md
  • Any breaking changes are highlighted above

@okgolove
Copy link
Contributor

okgolove commented Feb 13, 2019

@syst0m hello!
Does Helm provider wait for EKS cluster if you use this variable?
Are there errors like:
Post http://localhost/apis/extensions/v1beta1/namespaces/kube-system/deployments: dial tcp [::1]:80: connect: connection refused
?

@syst0m
Copy link
Contributor Author

syst0m commented Feb 15, 2019

@okgolove I cannot reproduce your error.
Can you elaborate a bit on your config?

@okgolove
Copy link
Contributor

I meant, I don't have kubectl config path output from EKS module (but you've added it within this PR) and my Helm provider isn't able to wait EKS module creates kubeconfig file. By default (without kubeconfig) Helm provider tries to access tiller via localhost.

Copy link

@loesak loesak left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks good to me

@loesak
Copy link

loesak commented Feb 17, 2019

@okgolove i believe, unless things have changed in the last year, that what you are referring to is a general problem with Terraform itself in that the output of resources from one provider cannot be used as input to another provider.

Where this change helps, at least for me, when you want to reference the output of Terraform state as the input to a different set of Terraform configuration.

outputs.tf Outdated
@@ -39,6 +39,11 @@ output "kubeconfig" {
value = "${data.template_file.kubeconfig.rendered}"
}

output "kubeconfig_filename" {
description = "The filename of the generated kubectl config."
value = "${local_file.kubeconfig.*.filename}"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If kubeconfig is disabled (var.write_kubeconfig = 0) this value won't work. Change this to:
value = ${element(concat(local_file.kubeconfig.*.filename, list("")), 0)}

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the suggestion, @antonbabenko .
I updated the PR.

@antonbabenko antonbabenko merged commit 6005cec into terraform-aws-modules:master Feb 18, 2019
@antonbabenko
Copy link
Member

v2.2.1 has been released.

@github-actions
Copy link

I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Nov 23, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants