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

coalesce-based workaround for import vs non-var entities? #15510

Open
handlerbot opened this issue Jul 8, 2017 · 0 comments
Open

coalesce-based workaround for import vs non-var entities? #15510

handlerbot opened this issue Jul 8, 2017 · 0 comments

Comments

@handlerbot
Copy link
Contributor

We're doing approximately this:

constants/main.tf

output "aws_account_id" {
  value = "0123456789012"
}

global/main.tf

module "constants" {
  source = "../constants"
}

provider "aws" {
  region = "us-west-2"

  allowed_account_ids = [
    "${module.constants.aws_account_id)}",
  ]
}

This works great, but of course, it breaks terraform import because of the provider's dependency on an interpolation from a source that isn't a variable.

I'm wondering how difficult it would be to modify ImportProviderValidateTransformer to consider this construct safe:

  allowed_account_ids = [
    "${coalesce(var.import_aws_account_id, module.constants.aws_account_id)}",
  ]

This would let us use modules-as-constants as we are happily doing so during normal operation, but for (rare) times when we're importing, we can make our existing config work via:

terraform import -var import_aws_account_id=0123456789012 ...

I'm glad to try and do the work if there are indications that a) it's possible given the data structures exposed to ImportProviderValidateTransformer and b) it would be reasonably likely to be accepted if I can get it working. :-)

Thanks for reading!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants