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

Interpolate variables in terraform backend config #12270

Closed
roderickrandolph opened this issue Feb 27, 2017 · 5 comments
Closed

Interpolate variables in terraform backend config #12270

roderickrandolph opened this issue Feb 27, 2017 · 5 comments

Comments

@roderickrandolph
Copy link

Terraform Version

Terraform v0.9.0-beta1

Affected Resource(s)

core

Terraform Configuration Files

provider "aws" { region = "us-east-1" }

terraform {
  backend "s3" {
    bucket = "my-bucket-${var.aws_region}"
    key = "${var.stack_name}.tfstate"
    region = "${var.aws_region}"
    encrypt = "1"
  }
}
variable "aws_region" { default = "us-east-1" }
variable "stack_name" { default = "my-stack" }

Debug Output

N/A

Panic Output

N/A

Expected Behavior

Terraform will interpolate all variables provided in the backend configuration (i.e. ${var.aws_region} and ${var.stack_name})

Actual Behavior

Terraform treats ${var.stack_name} and ${var.aws_region} as literal strings causing a terraform plan/apply to fail.

Error loading state: InvalidEndpointURL: invalid endpoint uri
caused by: parse https://s3.${var.aws_region}.amazonaws.com/{Bucket}/{Key+}: invalid character "{" in host name

Steps to Reproduce

Please list the steps required to reproduce the issue, for example:

  1. terraform init
  2. terraform plan
@mitchellh
Copy link
Contributor

This isn't allowed and beta 2 will properly give you an error message. Rather than re-explain, I'll link you to the PR with the discussion we had! #12067 We do want you to be able to parameterize backends but for now that'll be restricted to partial configs with -backend-config on init.

@roderickrandolph
Copy link
Author

roderickrandolph commented Feb 27, 2017

Thank you. I didn't realize there was a previous discussion on this topic. I actually looked before opening this issue too.

General feedback:
From a UX perspective the previous behavior of passing in multiple -backend-config as K/V pairs on the command line was preferred over the new behavior of generating a separate throw away config file for each environment stack. Overall, I like the new terraform init direction but the partial backend config file seems like a step backwards from a UX perspective.

Also, given the argument name I initially assumed -backend-config for terraform init would behave like it did for terraform remote config and accept K/V pairs. After reading the docs more closely I realized it takes a file path instead. Others will probably have similar experiences too as they make the transition to 0.9. Perhaps a different argument name could reduce the confusion. Just a thought.

@mitchellh
Copy link
Contributor

@roderickrandolph That's a good point. The reason we did away with K/V was that it left data in your CLI history, but I can see how it is much easier than the file-based approach. Let me think about it a bit. Thanks!

@sarmadali20
Copy link

@roderickrandolph what's the better UX alternative for this? I ran into this problem trying to store state files of k8s cluster in Artifactory so that Jenkins pipeline can create clusters on demand.

@ghost
Copy link

ghost commented Apr 3, 2020

I'm going to lock this issue 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 similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@hashicorp hashicorp locked and limited conversation to collaborators Apr 3, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants