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

Terraform output needs an option to exclude the provider block #386

Closed
jaygorrell opened this issue Aug 30, 2016 · 18 comments
Closed

Terraform output needs an option to exclude the provider block #386

jaygorrell opened this issue Aug 30, 2016 · 18 comments
Labels
area/terraform lifecycle/rotten P1
Milestone

Comments

@jaygorrell
Copy link

@jaygorrell jaygorrell commented Aug 30, 2016

Since one of the primary purposes of the Terraform output is to fit into an existing TF environment, the provider block is likely to already exist. It would be great if there were a simple flag to --include-provider=[true|false].

It may even make sense to default to false given what I assume to be the more common workflow.

@justinsb justinsb added this to the 1.3.0 milestone Sep 1, 2016
@justinsb justinsb added the P1 label Sep 1, 2016
@justinsb
Copy link
Member

@justinsb justinsb commented Sep 1, 2016

Great suggestion - I'll see what can be done.

@shamil
Copy link
Contributor

@shamil shamil commented Sep 1, 2016

This can be easily done using terrsform itself, not sure putting that logic inside kops will not over complicate things. kops should keep things simple.

Terraform supports overrides nativelly. So you could put an override.tf file in the same directory where kops outputs the terraform confgs. The override.tf file could contain something like:

provider "aws" {
  region = "us-east-1"
  access_key = "XXXXXXXXXXXXXXXXXXXX"
  secret_key = "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
}

That's it, now when you apply the configs, terraform will know to use your provider instead of kops's one. In my case I do lot's of overrides without affecting kops generated configs whatsoever. Works for me for long time without issues.

Read more about terraform overrides: https://www.terraform.io/docs/configuration/override.html

@jaygorrell
Copy link
Author

@jaygorrell jaygorrell commented Sep 1, 2016

I'll defer to @justinsb on the ticket itself but that's a really great suggestion, @shamil. It should solve my specific problem... thanks!

@kris-nova kris-nova modified the milestones: 1.4.3, 1.4.2 Nov 28, 2016
@kris-nova
Copy link
Member

@kris-nova kris-nova commented Nov 28, 2016

@justinsb - Stretch goal for 1.4.2

@justinsb justinsb modified the milestones: 1.4.5, 1.5.0 Dec 28, 2016
@justinsb justinsb added the area/terraform label Jan 3, 2017
@justinsb
Copy link
Member

@justinsb justinsb commented Jan 8, 2017

Slight problem ... we need to specify the region. That's why we're outputing the block (there is nothing else in there). Is there a terraform trick I'm missing?

@jaygorrell
Copy link
Author

@jaygorrell jaygorrell commented Jan 8, 2017

Odds are if someone is using TF output from Kops they're already using TF and have a provider with a region specified. Given that, my thought was that the block itself could be optional because what Kops outputs may not be exactly right for the user (ie. they have access keys being passed to the provider, or an alias).

The block is definitely needed, it's just a question of where it comes from.

@chrislovecnm
Copy link
Member

@chrislovecnm chrislovecnm commented Jan 9, 2017

Can you mock up something for us? Even better if you can contribute ;)

@jaygorrell
Copy link
Author

@jaygorrell jaygorrell commented Jan 9, 2017

I'd love to contribute but I need to get past the intimidation factor of a new unknown project ...oh, and learn Go.

As a mockup, I'm not sure what it'd look like really. The only thing you'd need is an extra flag used with the TF output to indicate if you want the provider or not. Since --target output is it's own flag, it currently doesn't support extra options. Maybe --target-options with some flags for different outputs would work but I don't know if that's heading down a bad path or not. Something like --target-options=noprovider.

Either way, this is unlikely still a P1 since @shamil posted a great workaround. The editor complains about duplicate providers being declared but the override takes precedence.

@chrislovecnm
Copy link
Member

@chrislovecnm chrislovecnm commented Jan 15, 2017

We have developer office hours, if you want to swing by and talk through changes. The Friday coming up at 9 am mt

@jaygorrell
Copy link
Author

@jaygorrell jaygorrell commented Jan 16, 2017

I'd love to make it to some of these but it conflicts with my daily standups - difficult for me to make things like this during business hours.

@kris-nova
Copy link
Member

@kris-nova kris-nova commented Jan 17, 2017

@jaygorrell can we set up a one off 1:1? Would love to meet you, and introduce you to the project.. touch base.. etc etc.. Doesn't need to be anything crazy.. just a quick hangout to go over introductions, talk about this issue, and the other topics you are involved in. Feel free to ping me on slack!

@jaygorrell
Copy link
Author

@jaygorrell jaygorrell commented Jan 23, 2017

Apologies for the delay but thanks for the offer @kris-nova ... I actually just got approval to attend these since we make heavy use of Kubernetes as part of the business. It may not be every time, but I'll do what I can when other pressing things aren't going on.

@justinsb
Copy link
Member

@justinsb justinsb commented Jan 30, 2017

Moving to 1.5.1, as the requirement isn't yet clear and 1.5.0 is hopefully imminent.

@justinsb justinsb modified the milestones: 1.5.1, 1.5.0 Jan 30, 2017
@erickt
Copy link
Contributor

@erickt erickt commented Nov 20, 2017

I had a workaround for this, where I was able to put my provider in a supermodule, and the kops terraform in a submodule, like this:

provider "aws" {
  profile = "some_profile"
  region = "us-west-2"
}

module "k8s" {
  source = "./kubernetes"
}

Terraform would then use the outer provider, not the inner one. Unfortunately it seems that Terraform 0.11's new provider support has broken this workaround, and now will error out with:

...

Error: Error refreshing state: 1 error(s) occurred:

* module.kubernetes.provider.aws: No valid credential sources found for AWS Provider.
  Please see https://terraform.io/docs/providers/aws/index.html for more information on
  providing credentials for the AWS Provider

I feel like the easiest solution would be for kops to not generate a provider, and document how to use the generated terraform as a module.

@erickt
Copy link
Contributor

@erickt erickt commented Nov 22, 2017

According to hashicorp/terraform#16721, there is now no way to override a provider in a submodule if any parameters are set, like the region. So it looks like we'll need to work around this somehow.

@justinsb justinsb modified the milestones: 1.5.2, 1.8.1 Dec 3, 2017
@justinsb justinsb modified the milestones: 1.8.1, 1.9 Feb 21, 2018
@fejta-bot
Copy link

@fejta-bot fejta-bot commented May 22, 2018

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

@k8s-ci-robot k8s-ci-robot added the lifecycle/stale label May 22, 2018
@justinsb justinsb modified the milestones: 1.9.0, 1.10 May 26, 2018
@fejta-bot
Copy link

@fejta-bot fejta-bot commented Jun 25, 2018

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten
/remove-lifecycle stale

@k8s-ci-robot k8s-ci-robot added lifecycle/rotten and removed lifecycle/stale labels Jun 25, 2018
@fejta-bot
Copy link

@fejta-bot fejta-bot commented Jul 25, 2018

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/terraform lifecycle/rotten P1
Projects
None yet
Development

No branches or pull requests

8 participants