Git Product home page Git Product logo

terraform-provider-template's Introduction

This Terraform provider is archived, per our provider archiving process. What does this mean?

  1. The code repository and all commit history will still be available.
  2. Existing released binaries will remain available on the releases site.
  3. Documentation will remain on the Terraform website.
  4. Issues and pull requests are not being monitored.
  5. New releases will not be published.

Please see #85 and the documentation for recommended replacements.


Terraform Provider

Maintainers

This provider plugin is maintained by the Terraform team at HashiCorp.

Requirements

  • Terraform 0.10.x
  • Go 1.11 (to build the provider plugin)

Usage

# For example, restrict template version in 0.1.x
provider "template" {
  version = "~> 0.1"
}

Building The Provider

Clone repository to: $GOPATH/src/github.com/terraform-providers/terraform-provider-template

$ mkdir -p $GOPATH/src/github.com/terraform-providers; cd $GOPATH/src/github.com/terraform-providers
$ git clone [email protected]:terraform-providers/terraform-provider-template

Enter the provider directory and build the provider

$ cd $GOPATH/src/github.com/terraform-providers/terraform-provider-template
$ make build

Using the provider

Fill in for each provider

Developing the Provider

If you wish to work on the provider, you'll first need Go installed on your machine (version 1.11+ is required). You'll also need to correctly setup a GOPATH, as well as adding $GOPATH/bin to your $PATH.

To compile the provider, run make build. This will build the provider and put the provider binary in the $GOPATH/bin directory.

$ make build
...
$ $GOPATH/bin/terraform-provider-template
...

In order to test the provider, you can simply run make test.

$ make test

In order to run the full suite of Acceptance tests, run make testacc.

Note: Acceptance tests create real resources, and often cost money to run.

$ make testacc

terraform-provider-template's People

Contributors

7heo avatar alexxnica avatar apparentlymart avatar appilon avatar bill-newsnow avatar catsby avatar clstokes avatar devinlundberg avatar ebekker avatar gechr avatar greut avatar grubernaut avatar jbardin avatar jen20 avatar josharian avatar katbyte avatar kmoe avatar krantzinator avatar lamdor avatar mitchellh avatar mvermaes avatar paultyng avatar phinze avatar quentin-m avatar radeksimko avatar sethvargo avatar sharkwouter avatar stack72 avatar tombuildsstuff avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

terraform-provider-template's Issues

template_file renders boolean values improperly while used in module

Hi there,

Terraform Version

> terraform -v
Terraform v0.11.3

Affected Resource(s)

  • template_file

Terraform Configuration Files

Template file chef_json_inputs/hbase.json.tpl

{
  "hadoop_server":{
    "hadoop_backup_enabled":${hadoop_backup_enabled},
    "hadoop_check_enabled":${hadoop_check_enabled},
  },
}

Properly working terraform config

format command is used instead of simple echo to keep output formatting the same as in original file and was copied from hashicorp/terraform#8090 (comment)

variable "hadoop_backup_enabled" { default = "false" }
variable "hadoop_check_enabled" { default = "false" }

data "template_file" "hbase_json" {
  template = "${file("chef_json_inputs/hbase.json.tpl")}"

  vars {
    hadoop_backup_enabled         = "${var.hadoop_backup_enabled}"
    hadoop_check_enabled          = "${var.hadoop_check_enabled}"
  }
}

resource "null_resource" "hbase_json" {

  provisioner "local-exec" {
    command = "${format("cat <<\"EOF\" > \"%s\"\n%s\nEOF", "/tmp/hbase.json", data.template_file.hbase_json.rendered)}"
  }
}

Output

/tmp/hbase.json

{
  "zsf_hadoop_server":{
    "hadoop_backup_enabled":false,
    "hadoop_check_enabled":false
  },
}

IMPROPERLY working module configs:

module/main.tf

variable "hadoop_backup_enabled" {}
variable "hadoop_check_enabled" {}

data "template_file" "hbase_json" {
  template = "${file("${path.module}/chef_json_inputs/hbase.json.tpl")}"

  vars {
    hadoop_backup_enabled         = "${var.hadoop_backup_enabled}"
    hadoop_check_enabled          = "${var.hadoop_check_enabled}"
  }
}

resource "null_resource" "example1" {
  provisioner "local-exec" {
    command = "${format("cat <<\"EOF\" > \"%s\"\n%s\nEOF", "/tmp/hbase.json", data.template_file.hbase_json.rendered)}"
  }
}

application/main.tf

module "render" {
  source = "../module"
  hadoop_backup_enabled         = false
  hadoop_check_enabled          = false
}

Output

/tmp/hbase.json

{
  "zsf_hadoop_server":{
    "hadoop_backup_enabled":0,
    "hadoop_check_enabled":0
  },
}

Expected Behavior

When the template is rendered, boolean values should remain the same as they were defined in the configuration, i.e. false remain false, and true is true, no transformation of false to 0 and true to 1 is needed.

Actual Behavior

When called directly without using modules, then false remains false, and true is true.
When the same functionality is moved to the module and got called, then false becomes 0 and true becomes 1.

Steps to Reproduce

terraform apply

Factoids

I also use the following command to ensure we could pass rendered template without any issues to a local file, but result was the same:
command = "echo '${data.template_file.hbase_json.rendered}' > /tmp/hbase.json"
and
command = "cat > /tmp/hbase.json <<EOL\n${data.template_file.hbase_json.rendered}\nEOL"

Quotes disappears in template

This issue was originally opened by @r-moiseev as hashicorp/terraform#17906. It was migrated here as a result of the provider split. The original body of the issue is below.


Terraform Version

Terraform v0.11.7
+ provider.azurerm v1.3.2
+ provider.helm (unversioned)
+ provider.kubernetes v1.1.0
+ provider.null v1.0.0
+ provider.template v1.0.0

Terraform Configuration Files

data "template_file" "inventory" {
  template = "${file("${path.module}/templates/inventory.tpl")}"

  vars {
   //  ..
    supplementary_address_in_ssl_keys = "${azurerm_public_ip.bedrock_master_ip.*.ip_address[0]}"
  }
}

And in template

[k8s-cluster:vars]
supplementary_addresses_in_ssl_keys= '["${supplementary_address_in_ssl_keys}"]'

Expected Behavior

I want to see this kind of output from template

[k8s-cluster:vars]
supplementary_addresses_in_ssl_keys = '["52.211.3.178"]'

Actual Behavior

But actually is:

[k8s-cluster:vars]
supplementary_addresses_in_ssl_keys = [52.211.3.178]

I wish to know where is quotes

File name too long

Hi,

using a template file in a rather deep directory structure and getting following error with terrafrom apply:

...
: file name too long

Terraform does not automatically rollback in the face of errors.
Instead, your Terraform state file has been partially updated with
2017-10-31T23:28:45.503+0100 [DEBUG] plugin: plugin process exited: path=/Users/foo009/workspace/engineering-enablement/ee-gocd-terraform/stage/google/.terraform/plugins/darwin_amd64/terraform-provider-template_v1.0.0_x4
2017-10-31T23:28:45.503+0100 [DEBUG] plugin: plugin process exited: path=/usr/local/Cellar/terraform/0.10.8/bin/terraform
any resources that successfully completed. Please address the error
above and apply again to incrementally change your infrastructure.

template_dir resource should support wildcarding on the source_dir attribute

Hi I would like to see the template_dir resource support wildcarding on the source_dir attribute.

template_dir renders all files within the source_dir directory. I would like to be able to specif a wildcard in the source-dir. For my use case this is to target a particular file type.

Terraform Version

Terraform v0.11.1

  • provider.aws v1.34.0
  • provider.local v1.1.0
  • provider.template v1.0.0

Affected Resource(s)

template_dir

Actual Behavior

resource "template_dir" "this" {
  source_dir      = "../templates/"
  destination_dir = "${path.root}/rendered"

  vars {
    foo= "bar"
  }
}

Expected Behavior

resource "template_dir" "this" {
  source_dir      = "../templates/*.tpl"
  destination_dir = "${path.root}/rendered"

  vars {
    foo= "bar"
  }
}

I'd like to keep my code DRY and not use template_file unless someone can suggest a way to use count in template_file and enumerate the .tpl files.

Directory management with the template or other provider

Terraform Version

0.12-dev

Affected Resource(s)

template provider, template_dir data source

Expected behavior

This is a proposal to improve the way user files are managed in Terraform.

One user story

User story: "I would like to deploy static websites to S3, using only Terraform."
Problem description:

  1. Fact nr.1: the current aws_s3_bucket_object is capable of uploading a well-defined file to S3
  2. Fact nr.2: Using count (or the soon-to-be for-each) it is possible to create a set of aws_s3_bucket_objects to upload a set of files. This requires a list-type variable that can be iterated.
  3. Problem nr.1: there is no Terraform-native way to read a list of files from a directory. (As mentioned in hashicorp/terraform/issues/16697 and worked around with https://github.com/saymedia/terraform-s3-dir)
  4. Problem nr.2: lists are not supported as Terraform input parameters (at least -var didn't support them a few versions ago).

So if I have a directory with a bunch of files (not exactly identified by name for Terraform), I have no way of iterating through them.
The one exception is, if they are templates and I need them rendered on the same machine. In that case the template_dir resource in the template provider will do it for me.

Generic user story

It seems that there are a few cases where people want to iterate through a directory. An additional one is hashicorp/terraform/issues/6065 where the user wants to use the file provisioner to keep a directory up-to-date but the file provisioner doesn't keep track of changes. It seems that a provider iterating through directories would be useful.

Originally, I thought this should be a custom directory provider and just write it for my use-case. Then I thought why not try to do it in a Terraform-native-way and try to integrate with the current providers.
The closest provider that iterates through directories is the already mentioned template_dir resource. Unfortunately, if I generally want to read the folders but not write them, I'm out of luck. As it was raised in #34, there is no template_dir data source, only resource.

Proposed solution nr.1 (already done)

New data source: template_dir. This can be considered a non-breaking improvement since it didn't exist before. Based on how the template_dir resource is defined (and trying to keep in line with it), here's how it would look like:

data "template_dir" "solution1" {
  source_dir = "website"   # Same as in the resource
  exclude = "\.tmp$"       # Improvement: regular expression applied to the relative path
  vars {                   # Same as in the resource
    "name": "mywebsite"
  }
  render: true             # Improvement: details below (consider files as templates)
}

Output variable rendered (same as in the resource) would be a map where the keys are the file names and optionally the values are the rendered files (in case of templates) or empty if render = false. (You can create a list of files using keys(data.template_dir.solution1.rendered) and iterate through it, for example to upload them to S3.)

So, the idea is to stuff this functionality into the template provider, even though the template provider is a bit more than just a file-system reader.

I already programmed this solution for 0.11 because I needed it for my use-case. Unfortunately, because of a bug in 0.11 (hashicorp/terraform/issues/19258), this will only work correctly in 0.12. I'm in the process of upgrading it and I'll share afterwards.

Pro: in-line with current expectations on how Terraform works; non-breaking change
Con: It's abusing the template provider to add functionality.

Proposed solution nr.2

New provider: io or built-in functions.
It seems that generic file reads (and writes) are in demand. In hashicorp/terraform/issues/16697 there is a discussion about a set of builtin functions to manage files in a directory. It seems that those discussions didn't amount to anything, but they might still be good ideas.

So the request: is it possible to get a bit of brainstorming together for an overarching solution? Is it better to use providers or builtin functions? I'm willing to look into any of it that makes sense because I would rather have a terraform-native solution (eventually) to this problem, than a custom provider.

Until a better idea emerges, I'll keep working on solution nr.1.

Extend a module's template file at the instance level

I cannot find this if it does exist. I'm looking for a way to define a template_file in a terraform module, and then "extend" / "append" to it at the instantiation level.

I've tried creating the template_file in the module, then creating an output in the module of the rendering. Then defining another template_file on the instantiation level and trying to reference the module's output as an interpolated value in the template file.

Doing so results in a unknown variable error.

Module file

data "template_file" "module_user_data_template" {
  template = "${file("${path.module}/user_data.sh.template")}"
}

output "module_template_file" {
  value = "${data.template_file.module_user_data_template.rendered}"
}

Instance main.tf

data "template_file" "user_data_template" {
  template = "${file("${path.module}/user_data.sh.template")}"
}


# Create External Proxy Server
module "my-module-instance" {
  source = "../../../../../modules/my-module"
}

Instance template file

"${module.my-module-instance.module_template_file}"

echo "Appended" > /tmp/a

Template provider - Better error message at template parsing

When the template file includes string such as ${$name}, terraform complains the tf file is incorrect although the error is in the template file.

Error: failed to render : <template_file>:1,4-5: Invalid character; This character is not used within the language., and 1 other diagnostic(s)

  on ecs_task.tf line 1, in data "template_file" "hoge":
   1: data "template_file" "hoge" {

Terraform Version

Run terraform -v to show the version. If you are not running the latest version of Terraform, please upgrade because your issue may have already been fixed.

Terraform v0.12.2
+ provider.aws v2.15.0
+ provider.local v1.2.2
+ provider.null v2.1.2
+ provider.template v2.1.2

Affected Resource(s)

  • template_file

Terraform Configuration Files

Template file content

"${$name}"

tf file content

data "template_file" "hoge" {
  template = file("path/to/template")
  vars = {
    name          = var.service_name
  }
}

Debug Output

Panic Output

Expected Behavior

Terraform error points to the template file, not the tf file.

Actual Behavior

Terraform error message is not helpful to identify the cause.

Steps to Reproduce

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

  1. terraform apply

Important Factoids

References

rendered template file unexpected behaviour (2 subsequent plan-apply needed instead of 1)

Terraform Version

v0.9.11

Affected Resource(s)

  • template_file

Terraform Configuration Files

provider "aws" {
  region     = "eu-central-1"
  #access and secret key is in ~/.aws/credentials
}

resource "aws_ecr_repository" "ecr_repo" {
  name = "ecr-repo"
}
data "template_file" "ecr_pol_inst_tmpl" {
  template = "${file("ECRPolicy_InstancePull.tpl")}"
  vars {
    instance_role = "${aws_iam_role.instance_role.arn}"
  }
}
resource "aws_ecr_repository_policy" "ecr_policy_instance_pull" {
  repository = "${aws_ecr_repository.ecr_repo.name}"
  policy = "${data.template_file.ecr_pol_inst_tmpl.rendered}"
}

resource "aws_iam_role" "instance_role" {
    name = "instance-role"
    assume_role_policy = "${file("AssumeRolePolicy.json")}"
}

Template file (ECRPolicy_InstancePull.tpl)

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "InstancePull",
            "Effect": "Allow",
            "Principal": {
                "AWS": "${instance_role}"
            },
            "Action": [
                "ecr:GetDownloadUrlForLayer",
                "ecr:BatchGetImage",
                "ecr:BatchCheckLayerAvailability"
            ]
        }
    ]
}

AssumeRolePolicy.json for the IAM role

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": "sts:AssumeRole",
      "Principal": {
        "Service": "ec2.amazonaws.com"
      },
      "Effect": "Allow",
      "Sid": ""
    }
  ]
}

Expected Behavior

With a terraform plan -out plan.tfplan and a terraform apply plan.tfplan all the resources should be created.

Actual Behavior

If I call plan, it looks good. When I apply that plan, it also seems like the dependencies are right, It wants to create the ECR repository policy with the rendered file (correct instance role ARN is in place in output). But AWS sends back InvalidParameterException: Invalid parameter at 'PolicyText' failed to satisfy constraint: 'Invalid repository policy provided' . The interesting part is if I call another plan + apply now, it creates the remaining resource (the ECR policy, what is using the template, also listing the right ARN in place) correctly. and in AWS console I see the wanted results.

I tried the same configuration with hardcoded (pre-existent ARN) without the template file data soruce, and it worked like a charm for the first try, but I need to be able to parameterize my policies, that's why I choose template files, (the IAM policy_document data source format is far less convenient format for me, I prefer providing the JSON for these things)

Steps to Reproduce

  1. terraform plan -out plan.tfplan
  2. terraform apply plan.tfplan
  3. AWS rejection happens, don't change anything
  4. terraform plan -out plan.tfplan
  5. terraform apply plan.tfplan
  6. It works just fine... ?!

Let terraform plan output rendered templates

This issue was originally opened by @llarsson as hashicorp/terraform#8669. It was migrated here as part of the provider split. The original body of the issue is below.


I use templates to generate user-data for my instances. As part of terraform plan, I care much more about what values the bootscript will be rendered with, rather than the template I passed in.

Could we get that as part of the output (possibly instead of merely echoing the template)?

Template File's count attribute within a module can't be computed when using interpolation syntax inside a list of map

This issue was originally opened by @YoannMa as hashicorp/terraform#15430. It was migrated here as a result of the provider split. The original body of the issue is below.


Hi,

First, thanks you all for your works ๐Ÿ‘

I encountered a problem when trying to generate commands line from a List of parameters.

My use case is for creating create database commands lines for a MySQL database and using the virtual network address for the host access value for the user. (I can't use the MySQL provider)

Terraform Version

v0.9.9

Terraform Configuration Files

main.tf

resource "random_id" "id" {
  byte_length = 32
}

module "commands" {
  source = "module_commands"

  values = [
    {
      var1 = "test"
      var2 = "${random_id.id.b64}"
    },
    {
      var1 = "test2"
      var2 = "${random_id.id.b64}"
    },
  ]
}

module_commands/main.tf

variable "values" {
  type        = "list"
  description = "List of map"
  default     = []
}

data "template_file" "commands" {
  count = "${length(var.values)}"

  template = <<EOF
  commandtodo $${var1} $${var2}}
EOF

  vars {
    var1 = "${lookup(var.values[count.index], "var1")}"
    var2 = "${lookup(var.values[count.index], "var2")}"
  }
}

output "values" {
  value = "${data.template_file.commands.*.rendered}"
}

Debug Output

https://gist.github.com/YoannMa/b200742d79638898cb68041608d5dd13

Expected Behavior

Compute the count value

Actual Behavior

Couldn't compute the count value

Steps to Reproduce

terraform plan or terraform apply

template_file needs the ability to use tfvars

This issue was originally opened by @digitalfiz as hashicorp/terraform#16863. It was migrated here as a result of the provider split. The original body of the issue is below.


For example right now we have a .json file for our task definitions and those task definitions have environment variables that change so we put them in the tfvars for each state.

The problem or more so the annoying thing is that we have to put the variable in the json file. Then make sure to put it in the vars for template_file and then also in the tfvars. So this exact same thing exists in 3 different places. Instead of 1 place for setting it and 1 place for using it.

It would be super useful if template_file had a flag or something to say just use whatever variables are available like all the other resources can do.

Provider doesn't support data source: terraform_remote_state

Terraform Version

v0.11.7

Affected Resource(s)

  • terraform_remote_state

Terraform Configuration Files

provider "aws" {
  region                  = "${var.aws_region}"
  shared_credentials_file = "${pathexpand(var.credentials_file_path)}"
  profile                 = "${var.profile_deployment}"
}

provider "aws" {
  alias  = "state"
  region = "${var.aws_region}"

  shared_credentials_file = "${pathexpand(var.credentials_file_path)}"
  profile                 = "${var.profile_state}"
}

data "terraform_remote_state" "alb" {
  provider = "aws.state"
  backend  = "s3"

  config {
    bucket = "${var.state_s3_bucket}"
    key    = "${var.alb_state_path["internal"]}/terraform.tfstate"
    region = "${var.aws_region}"
  }
}

Debug Output

data.terraform_remote_state.alb: Provider doesn't support data source: terraform_remote_state

Expected Behavior

The script should have grab the state files using the non default provider

Actual Behavior

It failed

Steps to Reproduce

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

  1. Fill in the variables
  2. Run 'terraform apply'

Important Factoids

This is used for a multi-account deployment for the script for the load balancer was deployed first.
The provider has different credentials for access the state files

template_dir deletes foreign files

This issue was originally opened by @mandelsoft as hashicorp/terraform#15365. It was migrated here as part of the provider split. The original body of the issue is below.


Terraform Version

0.9.8

Problem

I want to process a bunch of templates into a given target directory. There are two groups of templates, wheras the processing of the second group is optional (meaning it depends on a condition used to set the count attribute). The second one might also be one or more template_file resources.

Basically template_dir looks like the ideal solution for this problem. Unfortunately it isn't if the target directory should be the same.

Actual Behavior

This resource is implemented in a way that treats the complete target directory as resulting resource.
The effect is that all additional files not described by the actual template source files are deleted, regardless whether they have been generated by a former execution of the template_dir resource or not.

As a result the content of the directory flickers, the first time terraform executes the folder is empty everything is fine, both resources generate their files into the commonly used target directory.
But for every second execution, the folder already contains files not known by the two resources,
Therefore they schedule the deletion of the files. If the second one, for example, is a template_file it sees the correct target content during the planning phase, and schedules no action.

So, every second execution this file vanishes and appears again. Similar strange things happen, if both resources are template_dirs.

Not working workarrounds

I tried to use separate target folders and copy the files to a common folder later on.
Unfortunately there is no trigger for the null_resource based on the target folder that triggers the copy step if the target folder is deleted. (for example a directory hash)

Expected Behavior

There are for sure scenarios where the actual behaviour is completely fine. But it would be a great improvement if there would be an option to tell the resource to handle only files covered by the resource and not the complete directory. This means, it should delete only files, if they were generated by a former execution of the template_dir resource.

Invalid character; This character is not used within the language., and 4 other diagnostic(s)

Hello

It seems like there was a change that occurred last night which caused my userdata template files to not render correctly.

My userdata template uses the line:
$convertedByte=%{[System.Convert]::ToString($byte,16)}
This has been rendering correctly, but as of last night, I began receiving this error:

data.template_file.ec2_instance_userdata: failed to render : <template_file>:295,14-14: Invalid character; This character is not used within the language., and 4 other diagnostic(s).

If I lock the provider to 1.9.9 or under, using this code, then the template renders correctly.

> provider "template" {
  version = "<= 1.9.9"
}

Versions:

  • Terraform v0.11.11
  • provider.aws v1.55.0

Thanks

Dicky

aws_instance cloud-init mutipart encoding, etc. issues.

This issue was originally opened by @ohlol as hashicorp/terraform#4794. It was migrated here as part of the provider split. The original body of the issue is below.


The docs specify that base64_encode is optional for template_cloudinit_config, but user_data seems to get encoded automatically in aws_instance (https://github.com/hashicorp/terraform/blob/master/builtin/providers/aws/resource_aws_instance.go#L356)

It also seems to get compressed without gzip parameter, but I'm not sure where that is happening.

Regardless of these, I am having problems using this resource: https://gist.github.com/ohlol/133fa79539c7d40c7adc

If I use template_file directly in the aws_instance resource, cloud-init works fine. Any time I use template_cloudinit_config as the value for user_data in aws_instance, it fails with the error shown in the gist.

go module uses invalid version

I am on go 1.13. If I do go get in module mode, I get the following error

go get github.com/terraform-providers/[email protected]
go: finding github.com/terraform-providers/terraform-provider-template v2.1.2
go get github.com/terraform-providers/[email protected]: github.com/terraform-providers/[email protected]: invalid version: module contains a go.mod file, so major version must be compatible: should be v0 or v1, not v2

I believe the issue is that go.mod exists on a tagged git version higher on a high major semver version than 1. To fix this problem, the module path needs a /v2 at the end

module github.com/terraform-providers/terraform-provider-template

See here for details:

https://github.com/golang/go/wiki/Modules#semantic-import-versioning

Extremely unprofessional backward incompatible release

It is my understanding (and experience) that the Terraform developers strive to provide backward compatibility. Releasing this prior to the official 0.12 release is not only premature, but unprofessional at best. It breaks the vast majority of our templates, forcing us to review every stack we have written since we adopted the tool. This release should never have happened.

Terraform Version

All versions prior to 0.12 (which has not been released at this time).

Affected Resource(s)

terraform_template

Terraform Configuration Files

data "template_file" "user_data" {
  template = "${file("${path.module}/user_data.tpl")}"
  vars {
    deployment_environment = "${var.environment}"
    nr_license_key = "${var.nr_license_key}"
  }
}

Expected Behavior

Correctly formatted shell script

Actual Behavior

Incorrectly formatted shell script that prevents instances from launching.

Steps to Reproduce

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

  1. terraform apply

Important Factoids

Standard ASG

References

Release 2.0.0 Changelog
https://github.com/terraform-providers/terraform-provider-template/blob/master/CHANGELOG.md

Make Terraform validate template_file on plan phase

This issue was originally opened by @fcappi as hashicorp/terraform#20770. It was migrated here as a result of the provider split. The original body of the issue is below.


Current Terraform Version

terraform -v
Terraform v0.11.10

Use-cases

Currently, when there is an issue with a template file like having a variable being used in the file that was not specified as input, terraform only fails at the apply phase. Then you have to destroy the infrastructure that is already created so far, fix the issue in the template file and then apply again. This can be time-consuming if you are creating many resources.

Attempted Solutions

Currently, you have to terraform destroy, fix the file and then terraform applyagain

Proposal

I think it would be great if Terraform validates the template files before starting applying all the changes, this way we can make sure it will not break during infrastructure creation.

template_file not re-rendering on change

Terraform Version

Terraform v0.11.0
+ provider.template v1.0.0

Affected Resource(s)

  • local_file
  • data.template_file

Terraform Configuration Files

data "template_file" "docker-compose" {
  template = "${file("${path.module}/docker-compose.yml.tpl")}"

  vars {
    # ...
  }
}

resource "local_file" "docker-compose" {
  content  = "${data.template_file.docker-compose.rendered}"
  filename = "${path.root}/docker-compose.yml"

  provisioner "local-exec" {
    command =  # ...
  }
}

Expected Behavior

When I modify docker-compose.yml.tpl, I expect data.template_file.docker-compose to be tainted, in turn tainting local_file.docker-compose.

Actual Behavior

Even if I terraform taint local_file.docker-compose manually, the rendered template is cached in tfstate, and I get the same rendered file back as before. Manually modifying the template_file to tainted: true in the tfstate also has no affect; presumably because data sources can't be tainted (so the existence of the attribute is a bit confusing in itself).

Other than changing local_file for a local-exec provisioner that redirects the rendered output to file, (which is nasty!) the only workaround I've found is to terraform state rm the offending data.

Steps to Reproduce

  1. terraform apply
  2. modify the template file
  3. terraform apply

Terraform template file not rendering

This issue was originally opened by @fstuck37 as hashicorp/terraform#15337. It was migrated here as part of the provider split. The original body of the issue is below.


I'm having an issue similar to one mentioned in hashicorp/terraform#11144 with variables within a script used in a template_file using Terraform v0.9.8
This is the portion of the script that I'm having issues with:

for i in "$${arr[@]}"
do
var1=$${i%:};
var2=$${i#
:};
done;

When used individually this errors within all three of the double dollar locations.
For example on the first line:
failed to render : parse error at 1:17: expected expression but found invalid sequence "@"

I'm thinking that since we escape the $ (using the double $) terraform should ignore what's with the {}.

This works as expected when the variable is a simple name for example:
echo " port = $${PORT}"

Any suggestions would be appreciated.
Thanks
Fred

Resource 'template_file.xxx' does not have attribute 'rendered' for variable 'template_file.xxx.rendered'

This issue was originally opened by @mattsoftware as hashicorp/terraform#3417. It was migrated here as part of the provider split. The original body of the issue is below.


After modifying the template referenced with new content, terraform does not seem to be able to render my file anymore. I cannot even destroy my infrastructure to fix the issue :/


matts-air:stage1singapore matt$ terraform plan
Error configuring: 1 error(s) occurred:

* Resource 'template_file.stage_users' does not have attribute 'rendered' for variable 'template_file.stage_users.rendered'

matts-air:stage1singapore matt$ terraform destroy
Do you really want to destroy?
  Terraform will delete all your managed infrastructure.
  There is no undo. Only 'yes' will be accepted to confirm.

  Enter a value: yes

Error configuring: 1 error(s) occurred:

* Resource 'template_file.stage_users' does not have attribute 'rendered' for variable 'template_file.stage_users.rendered'

Increment template

This issue was originally opened by @SDBrett as hashicorp/terraform#15476. It was migrated here as a result of the provider split. The original body of the issue is below.


I'm using a template to provide initial configuration data for my EC2 instances. Part of that configuration is to set a host name using a defined prefix and the counter as a suffix.

The result is all instances are getting the same name 0, as 0 is the first counter index. I use the same variable to set apply tags to the EC2 instance and node in chef and they increment just fine. The only place it doesn't is with the template.

On face value it appears that the template does not not reevaluate the passed variables after they are first set.

The temple resource is configured as

data "template_file" "file_server" {
  template = "${file("userdata.txt")}"
  vars {
    admin_password="${var.administrator_pw}"
    hostname = "${var.file_server.["hostname_prefix"]}-${count.index}"
  }
}

It is applied against the AWS resource as

[user_data = "${data.template_file.file_server.rendered}"]

In the user data file I am referring to the variable with the following line

Rename-Computer -NewName "${hostname}" -Restart -Confirm:$False

I would expect that my servers are named fs-0, fs-1 ..... but the host name is set as fs-0 for every server.

This is on Terraform 0.9.6

template_cloudinit_config adding headers in rendered user-data

This issue was originally opened by @jonaskint as hashicorp/terraform#12204. It was migrated here as part of the provider split. The original body of the issue is below.


Terraform Version

Terraform v0.8.7

Affected Resource(s)

  • template_cloudinit_config

Terraform Configuration Files

data "template_file" "controller" {
  template = "${file("${path.module}/template/controller_user_data.yml")}"

  vars {
    CA_PEM               = "${base64encode(var.ca-key)}"
    CA_CERT              = "${base64encode(var.ca-cert)}"
    ETCD_ENDPOINT        = "https://${var.etcd_endpoint}:2379"
    ETCD_DNS             = "${var.etcd_endpoint}"
    POD_NETWORK          = "172.16.0.0/16"
    K8S_VER              = "v1.5.2_coreos.0"
    HYPERKUBE_IMAGE_REPO = "quay.io/coreos/hyperkube"
    DNS_SERVICE_IP       = "172.17.0.10"
    SERVICE_IP_RANGE     = "172.17.0.0/24"
    NETWORK_PLUGIN       = "cni"
    REGION               = "${var.region}"
  }
}

data "template_cloudinit_config" "controller" {
  gzip          = false
  base64_encode = false

  part {
    content = "${data.template_file.controller.rendered}"
  }
}

resource "aws_instance" "controller" {
  ami           = "${var.ami}"
  instance_type = "${var.instance_type}"
  count         = "${var.count}"

  subnet_id = "${element(var.subnet_ids, count.index)}"

  # Prevent terraform booboos where the etcd cluster gets deleted. Now we need to delete them manually.
  //  disable_api_termination              = "true"
  disable_api_termination = "false"

  instance_initiated_shutdown_behavior = "stop"

  key_name             = "${var.key_name}"
  user_data            = "${data.template_cloudinit_config.controller.rendered}"
  security_groups      = ["${aws_security_group.controller.id}"]
  iam_instance_profile = "${aws_iam_instance_profile.controller.id}"

  root_block_device {
    volume_size           = 40
    volume_type           = "gp2"
    delete_on_termination = true
  }

  tags {
    Name        = "${var.name}-controller${count.index}"
    Environment = "${var.environment}"
    Region      = "${var.region}"
    Os          = "ContainerLinux"
  }

  lifecycle {
    create_before_destroy = true
    ignore_changes        = ["security_groups", "user_data"]
  }
}

Expected Behavior

Content of user-data through AWS console

#cloudconfig
...

Actual Behavior

Actual content of user-data through AWS console

Content-Type: multipart/mixed; boundary="MIMEBOUNDARY"
MIME-Version: 1.0
--MIMEBOUNDARY
Content-Transfer-Encoding: 7bit
Content-Type: text/plain
Mime-Version: 1.0

#cloud-config
...

Steps to Reproduce

Had an oversized user-data file that was being used through a simple 'template_file' data resource and because of the AWS limit in the api, I started using 'template_cloudinit_config' data resource to make it more compact. After the apply, I noticed the node was stuck during initialisation and I could not retrieve the user-data through the AWS console.

So I did a second apply with gzip and base64 turned off and the half of my user-data file in order to trouble shoot the 'template_cloudinit_config' resource and noticed the extra headers in the user-data through the AWS console (vm didn't come up either and was stuck during init).

Important Factoids

AWS ec2 instance

depends_on should wait for template_dir generation

This issue was originally opened by @aosman-tibco as hashicorp/terraform#23684. It was migrated here as a result of the provider split. The original body of the issue is below.


Terraform Version

Terraform v0.12.18
+ provider.aws v2.41.0
+ provider.template v2.1.2

Terraform Configuration Files

resource "template_dir" "policies" {
  source_dir      = var.policies
  destination_dir = "${path.cwd}/policies"

  vars = {
    email   = var.recipient_email
    sqs_url = aws_sqs_queue.foo.id
  }
}

resource "aws_s3_bucket_object" "policies" {
  depends_on  = [template_dir.policies]
  for_each    = fileset(template_dir.policies.destination_dir, "**/*")

  bucket      = data.aws_s3_bucket.this.id
  key         = "policies/${each.value}"
  source      = "${template_dir.policies.destination_dir}/${each.value}"
  etag        = filemd5("${template_dir.policies.destination_dir}/${each.value}")

}

Expected Behavior

Templates are generated and aws_s3_bucket_object is aware of them (causing them to be uploaded)

Actual Behavior

Templates are generated and aws_s3_bucket_object is not aware of them, therefore no action is taken. A second apply is required to upload the generated files.
If the generated files are deleted, the aws_s3_bucket_object detects the source files as missing then then deletes the resources (even if the files are generated again). A second apply is required to upload the generated files.

Steps to Reproduce

  1. terraform init
  2. terraform apply

Additional Context

References

Unexpected diff in rendered template file

Hi

I have a strange problem with a template_file which causes a diff every time I run a plan/apply.
I've tracked the cause of the problem down to the depends_on declared in my template_file resource. If the depends_on is there, it causes a diff, despite the fact that no values from the dependant resource are used within the template/template variables. I've even checked the rendered content in the remote state vs the rendered content locally and they're identical in every way, right down to line endings and white space. If I remove the depends_on, it works as expected and there is no diff. I can work around the issue but thought I'd point it out as it was unexpected.

Terraform Version

0.10.2

Affected Resource(s)

  • data.template_file

Terraform Configuration Files

data "aws_s3_bucket_object" "archive" {
  bucket = "${var.bucket}"
  key    = "${var.product}/${var.service}/${var.service}-${var.version}.zip"
}

data "template_file" "user_data" {
  depends_on = ["data.aws_s3_bucket_object.archive"]
  template   = "${file("${path.module}/templates/userdata.ps1")}"

  vars {
    bucket  = "${var.bucket}"
    key     = "${var.product}/${var.service}/${var.service}-${var.version}.zip"
    service = "${var.service}"
    version = "${var.version}"
  }
}

Expected Behavior

No diff during plan/apply

Actual Behavior

Causes a diff when running plan/apply

Steps to Reproduce

  1. terraform plan

Additional Info

The reason for my seemingly unused depends_on is that my userdata for my launch configs has script to pull an object from an S3 bucket. If the object doesn't exist in S3 at the point I run apply, I have to wait 10-20 minutes for the new ASG to bring all it's instances up and then timeout waiting on the ELB health check because the instances never became healthy because the userdata failed because the S3 object didn't exist. By adding the depends_on, it simply ensures that the S3 object exists before it attempts to bring everything up and if it doesn't exist, will fail immediately and prevent wasting time and money in AWS. I can move the depends on to my launch configs but the reason I had it on the userdata was the userdata is shared by multiple launch configs.

If you would like any additional info just give me a shout.

Thanks!

Absolute paths in Statefile

Output from template and local providers store absolute path in statefile.

This causes issues when using remote state and working in a team

Perhaps this is a known issue, please point me to related tickets or suggested workarounds as I was unable to find any so far.

Terraform Version

terraform -v
Terraform v0.10.2

Affected Resource(s)

Please list the resources as a list, for example:

  • template_dir

Terraform Configuration Files

# in the bootstrap module:
resource "template_dir" "configs" {
  source_dir      = "${path.module}/resources/configs"
  destination_dir = "./generated/bootstrap/configs"

  vars {
    # template variables here
  }
}

# in the root project - modules.tf
module "my_module" {
  source         = "./modules/bootstrap"
  # module config here
}

Debug Output

module.my_module.template_dir.configs: 1 error(s) occurred:

* module.my_module.template_dir.configs: template_dir.configs: could not generate output checksum: lstat /Users/path/to/root/project/.terraform/modules/0a870bfa99885a552018aa68a1aac335/resources/configs: no such file or directory

Expected Behavior

Relative paths should be stored in statefile instead of Absolute paths

Actual Behavior

Absolute paths are stored in statefile and cause lstat errors on terraform refresh

Steps to Reproduce

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

  1. keep terraform plan on different paths between laptop 1 and laptop 2
  2. use remote state and terraform init both laptops
  3. on laptop 1 run terraform apply
  4. on laptop 2 run terraform refresh

template_dir can't handle subdirectories correctly on windows: open <filename>: The system cannot find the path specified.

Terraform Version

Terraform v0.12.12

  • provider.template v2.1.2

Affected Resource(s)

  • template_dir

Terraform Configuration Files

Only occurs with source directory that contains subdirectories

https://github.com/poseidon/terraform-render-bootstrap/blob/10d9cec5c256f4622712bf01448df1a2befc37c8/assets.tf#L18-L32

input  
โ””โ”€โ”€ manifests
    โ””โ”€โ”€ foo.txt
resource "template_dir" "manifests" {
  source_dir      = "input"
  destination_dir = "output"
  vars = {}
}

Debug Output

https://gist.github.com/vroad/5e29d07886bf66af4a613729465847b9
https://gist.github.com/vroad/8d0bc9b8f69c7a397599946b6d8d9852

Error: open output/dir\foo.txt: The system cannot find the path specified.

Only last path separator is \ (backslash), not / (slash). Might be related.

Panic Output

Expected Behavior

It should generate files in subdirectories as well.

Actual Behavior

No files generated and terraform stops with an error. Only occurs on windows. When running terraform from docker, it successfully generate files.

Steps to Reproduce

On powershell,

  1. mkdir input\manifests
  2. echo foo > input\manifests\foo.txt
  3. terraform apply

Important Factoids

I updated an example with minimal one.

References

Are there any other GitHub issues (open or closed) or Pull Requests that should be linked here? For example:

template_file resource unknown variable accessed

This issue was originally opened by @ewilde as hashicorp/terraform#12520. It was migrated here as a result of the provider split. The original body of the issue is below.


Part of a larger terraform script is failing when rendering a simple template

Terraform Version

Terraform v0.8.8

Affected Resource(s)

  • template_file

Terraform Configuration Files

variable "name" {
}

variable "environment" {
}

variable "account_id" {
}

data "template_file" "policy" {
  template = "${file("${path.module}/policy.json")}"

  vars = {
    bucket_name = "${var.name}-${var.environment}-logs"
    account_id  = "${var.account_id}"
  }
}

resource "aws_s3_bucket" "logs" {
  bucket = "${var.name}-${var.environment}-logs"

  tags {
    Name        = "${var.name}-${var.environment}-logs"
    Environment = "${var.environment}"
    Stack       = "${var.name}"
  }

  policy = "${data.template_file.policy.rendered}"
}

output "id" {
  value = "${aws_s3_bucket.logs.id}"
}

Policy json

{
  "Id": "log-bucket-policy",
  "Statement": [
    {
      "Sid": "AWSCloudTrailAclCheck20150319",
      "Effect": "Allow",
      "Principal": {
        "Service": "cloudtrail.amazonaws.com"
      },
      "Action": "s3:GetBucketAcl",
      "Resource": "arn:aws:s3:::${bucket_name}"
    },
    {
      "Action": "s3:PutObject",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::${account_id}:root",
        "Service": "cloudtrail.amazonaws.com"
        },
      "Resource": "arn:aws:s3:::${bucket_name}/*",
      "Sid": "log-bucket-policy"
    }
  ],
  "Version": "2012-10-17"
}

Debug Output

https://www.dropbox.com/s/iwt5h3xxf8w1ot6/debug.log.gpg?dl=0

Expected Behavior

Template resource should render

Actual Behavior

Error message:

Error applying plan:

1 error(s) occurred:

* data.template_file.policy: failed to render : 11:35: unknown variable accessed: bucket_name

Steps to Reproduce

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

  1. terraform apply

template_dir doesn't skip hidden files

Terraform Version

Terraform v0.12.6, template provider v2.1.2

Affected Resource(s)

Please list the resources as a list, for example:

Terraform Configuration Files

provider template {}

resource "template_dir" "config" {
  source_dir      = "${path.module}/instance_config_templates"
  destination_dir = "${path.cwd}/instance_config"
}

Where instance_config_templates let's say is a git submodule, so it has .git directory inside.

Debug Output

$terraform apply
template_dir.config: Refreshing state... [id=d1cde20a34d2c848136a151c73453d8ee6b680b9]

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # template_dir.config will be created
  + resource "template_dir" "config" {
      + destination_dir = "/tmp/a/instance_config"
      + id              = (known after apply)
      + source_dir      = "./instance_config_templates"
    }

Plan: 1 to add, 0 to change, 0 to destroy.

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

template_dir.config: Creating...

Error: failed to render instance_config_templates/.git/hooks/applypatch-msg.sample: <template_file>:14,47-51: Invalid operand; Unsuitable value for right operand: a number is required.

  on main.tf line 3, in resource "template_dir" "config":
   3: resource "template_dir" "config" {

Expected Behavior

Hidden files (starting with dot) should be skipped, or at least there should be a configuration option to skip files by using a pattern.

Actual Behavior

It tries to render instance_config_templates/.git/hooks/applypatch-msg.sample as a template and fails.

Steps to Reproduce

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

  1. terraform apply

Important Factoids

None

References

None

* provider.template: version = "~> 0.1"

Hi there,

Terraform Version

0.10.0

Affected Resource(s)

  • provider.template

Terraform Configuration Files

data "template_file" "init" {
  template = "${file("init.tpl")}"

  vars {
    consul_address = "${aws_instance.consul.private_ip}"
  }
}

Debug Output

terraform init -backend-config=config/backend.conf

Initializing the backend...

Initializing provider plugins...
- Downloading plugin for provider "template"...
- Downloading plugin for provider "aws"...

The following providers do not have any version constraints in configuration,
so the latest version was installed.

To prevent automatic upgrades to new major versions that may contain breaking
changes, it is recommended to add version = "..." constraints to the
corresponding provider blocks in configuration, with the constraint strings
suggested below.

* provider.aws: version = "~> 0.1"
* provider.template: version = "~> 0.1"

Terraform has been successfully initialized!

...

Questions

I have to guess how to set provider template version and below codes work in fact.

provider "template" {
  version = "~> 0.1"
}

Can anyone confirm if this is the right way to lock provider template version? If it is, I can raise PR to update in README.

Updates:

Seems provider template doesn't support key region.

 * provider.template: : invalid or unknown key: region

Indent function in template file failed to render

This issue was originally opened by @sebastien-prudhomme as hashicorp/terraform#16775. It was migrated here as a result of the provider split. The original body of the issue is below.


Terraform Version

Terraform v0.11.0 and Terraform v.0.10.8

Terraform Configuration Files

resource "tls_private_key" "ca" {
  algorithm = "RSA"
  rsa_bits  = "2048"
}

data "template_file" "config-yaml" {
  template = "${file("${path.module}/config.yaml.tpl")}"

  vars {
    ca_rsa_private = "${tls_private_key.ca.private_key_pem}"
  }
}

config.yaml.tpl:

ca_rsa_private: |
  ${indent(2, ca_rsa_private)}

Expected Behavior

No error

Actual Behavior

Got this error:

failed to render : 2:5: unknown function called: indent

Important Factoids

If i use the indent function directly in the TF file, it works fine.

data "template_file" "config-yaml" {
  template = "${file("${path.module}/config.yaml.tpl")}"

  vars {
    ca_rsa_private = "${indent(2, tls_private_key.ca.private_key_pem)}"
  }
}

config.yaml.tpl:

ca_rsa_private: |
  ${ca_rsa_private}

The new 2.0.0 doesn't parse %${var} core

The updated template_file data source incorrectly parses template files when you have the sequence %${var} in it. It looks like the % messes up the parser so that it doesn't interpret the ${var}, but I can't find any way to escape this. This is a breaking issue for me, as the % is required for correct sudo syntax.

Terraform Version

Terraform v0.11.11

  • provider.template v2.0.0

Affected Resource(s)

Please list the resources as a list, for example:

  • data.template_file

If this issue appears to affect multiple resources, it may be an issue with Terraform's core, so please mention this.

Terraform Configuration Files

data "template_file" "sudoers" {
  template = "${file("${path.module}/tpls/sudoers.tpl")}"
  vars {
    metagroup = "mymetagroup"
  }
}

output "sudoers" {
  value = "${data.template_file.sudoers.rendered}"
}
# Give ${metagroup} sudo access
%${metagroup} ALL=(ALL:ALL) ALL

Expected Behavior

terraform apply
data.template_file.sudoers: Refreshing state...

Apply complete! Resources: 0 added, 0 changed, 0 destroyed.

Outputs:

sudoers = # Give mymetagroup sudo access
%mymetagroup ALL=(ALL:ALL) ALL

Actual Behavior

terraform apply
data.template_file.sudoers: Refreshing state...

Apply complete! Resources: 0 added, 0 changed, 0 destroyed.

Outputs:

sudoers = # Give mymetagroup sudo access
%${metagroup} ALL=(ALL:ALL) ALL

Steps to Reproduce

  1. mkdir -p testit/tpls
  2. put the hcl from above into testit.tf
  3. put the other data above into tpls/sudoers.tpl
  4. terraform apply

Passing Lists as Template Variables

Hi there,

Thank you for opening an issue. Please note that we try to keep the Terraform issue tracker reserved for bug reports and feature requests. For general usage questions, please see: https://www.terraform.io/community.html.

Terraform Version

Terraform v0.12.8

  • provider.aws v2.27.0
  • provider.template v2.1.2

Affected Resource(s)

Please list the resources as a list, for example:
template_file

Terraform Configuration Files

data "template_file" "kops_config" {
  template = file("${path.module}/config.tpl")
  vars     = {
    aws_account_id     = data.aws_caller_identity.current.account_id
    availability_zones = data.aws_availability_zones.available.names
  }
}

Debug Output

Error: Incorrect attribute value type

on kops_config.tf line 3, in data "template_file" "config":
3: vars = {

Inappropriate value for attribute "vars": element "availability_zones": string
required.

Expected Behavior

Since in templates %{for } loops now possible I would expect there is a way to pass the list to template as variable

Actual Behavior

List is not accepted as string is required

Steps to Reproduce

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

  1. terraform apply

References

This is kind of re-openning of #40 since there was nothing done to fix this issue.

Unable to "loop" through a list in a template

Hi there,

Terraform Version

Terraform v0.11.1

  • provider.aws v1.1.0
  • provider.template v1.0.0

Terraform Configuration Files

resource "template_file" "haproxy_cfg" {                                                                                          
  count = "${len(var.backend_ips)}"                                                                                               
  template = "${file("${path.module}/templates/haproxy.cfg.tpl")}"                                                                
                                                                                                                                  
  vars {                                                                                                                          
    backend_name = "${var.backend_name}"                                                                                          
    backends = "${var.backend_ips}"                                                                                               
    balance = "${var.balance_method}"                                                                                             
    mycount = "${count.index}"                                                                                                    
  }                                                                                                                               
}
global                                                                                                                            
  daemon                                                                                                                          
  maxconn 8192                                                                                                                    
                                                                                                                                  
defaults                                                                                                                          
  timeout connect 5000ms                                                                                                          
  timeout client 50000ms                                                                                                          
  timeout server 50000ms                                                                                                          
  option redispatch                                                                                                               
  retries 3                                                                                                                       
                                                                                                                                  
frontend http-in:                                                                                                                 
  bind *:80                                                                                                                       
  default_backend "${backend_name}"                                                                                               
                                                                                                                                  
frontend https-in:                                                                                                                
  bind *:443                                                                                                                      
  default_backend "${backend_name}"                                                                                               
                                                                                                                                  
backend "${backend_name}"                                                                                                         
  balance "${var.balance_method}"                                                                                                 
  mode http                                                                                                                       
  option httpchk GET /healthz                                                                                                        
  server server"${var.mycount}" "${element(${var.backends}, ${var.mycount})}":8888 weight 1 maxconn 1685 check          

Expected Behavior

I'd like to see one template instantiation with five server lines.

Actual Behavior

I'm going to get five files with one server line each

Important Factoids

I might (and am likely) to be missing some dead-simple way of doing this...but an hour of googles and githubs hasn't helped me. This isn't a very searchable problem.

Provider doesn't support data source: template_dir

This issue was originally opened by @redscaresu as hashicorp/terraform#18535. It was migrated here as a result of the provider split. The original body of the issue is below.


Terraform Version

Terraform v0.11.7

Terraform Configuration Files

data "template_dir" "opt_bin_foo" {
  source_dir = "${path.module}/../data/foo"
  destination_dir = "/opt/bin/foo"
}

### Crash Output
<!--
Error: module.app1_data_1.data.template_dir.opt_bin_foo: Provider doesn't support data source: template_dir
-->

### Expected Behavior
<!--
Allow me to create a data construct for template_dir
-->

### Actual Behavior
<!--
failed because the provider does not support the data source for template_dir
-->

### Steps to Reproduce
<!--
1. `terraform init`
2. `terraform apply`
-->

### Additional Context
<!--
Hi, if there a design reason why this functionality is not already included please free to
let me know.  It would be really useful to be able to use this functionality especially in
the context coreos ignition.  I have not included the debug output because it feels
like this is simply a case of missing functionality.
-->

Template 2.0.0 tries to interpulate percent (%) signs followed by curly-braces {}

Hi there,

Thank you for opening an issue. Please note that we try to keep the Terraform issue tracker reserved for bug reports and feature requests. For general usage questions, please see: https://www.terraform.io/community.html.

Terraform Version

Terraform v0.11.7
+ provider.archive v1.1.0
+ provider.aws v1.38.0
+ provider.dyn v1.1.0
+ provider.local v1.1.0
+ provider.null v1.0.0
+ provider.random v2.0.0
+ provider.template v2.0.0

Your version of Terraform is out of date! The latest version
is 0.11.11. You can update by downloading from www.terraform.io/downloads.html

Affected Resource(s)

Please list the resources as a list, for example:

  • template_file

Terraform Template body

status=$(curl $ETCD_CURLOPTS -f -s -w **%{http_code}** "$etcd_good_member_url/v2/members/$bp" -XDELETE)

^^^ the %{http_code} causes the error

Debug Output

* module.MY_MODULE.data.template_file.install_script: data.template_file.install_script: failed to render : <template_file>:153,57-66: Invalid template control keyword; "http_code" is not a valid template control keyword.

Expected Behavior

TF template provider should not try to interpulate percent signs.

Actual Behavior

See Debug Output

Steps to Reproduce

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

  1. Create a template with %{http_code} as body
  2. Using TF 0.11.7, try to render the template.

Thank you in advance,
Yarden

issue with User_data template

Hi there,

Terraform Version

0.9.8

Affected Resource(s)

data "template_file"

Terraform Configuration Files

provider "aws"{
region="${var.aws_region}"
access_key="${var.access_key}"
secret_key="${var.secret_key}"
}
resource "aws_security_group" "default"{
name="Sensu-sg"
description="Created for sensu installation"
vpc_id="vpc-3918dc5f"

ingress{
    from_port = 22
    to_port = 22
    protocol= "tcp"
    cidr_blocks = ["10.0.0.0/8", "43.0.0.0/8","160.33.244.0/23","160.33.246.0/23"]
}
ingress{
    from_port = 2380
    to_port = 2380
    protocol= "tcp"
    cidr_blocks = ["10.0.0.0/8", "43.0.0.0/8"]
}
ingress{
    from_port = 3000
    to_port = 3000
                                                                                      1,1           Top
ingress{
    from_port = 3000
    to_port = 3000
    protocol= "tcp"
    cidr_blocks = ["10.0.0.0/8", "43.0.0.0/8"]
}
ingress{
    from_port = 8080
    to_port = 8080
    protocol= "tcp"
    cidr_blocks = ["10.0.0.0/8", "43.0.0.0/8"]
}
ingress{
    from_port = 8081
    to_port = 8081
    protocol= "tcp"
    cidr_blocks = ["10.0.0.0/8", "43.0.0.0/8"]
}
ingress{
    from_port = 80
    to_port = 80
    protocol = "tcp"
    cidr_blocks = ["10.0.0.0/8", "43.0.0.0/8"]
}
egress {
from_port   = 0
to_port     = 0
protocol    = "-1"
cidr_blocks = ["0.0.0.0/0"]

}

}

data "template_file" "init" {
template = "${file("init.tpl")}"
}

resource "aws_instance" "Sensu_docker"{
instance_type="m3.medium"
ami="${lookup(var.aws_ami, var.aws_region)}"
key_name = "sneelakantan"
iam_instance_profile = "confluence_instance_role"
security_groups = ["${aws_security_group.default.id}"]
subnet_id = "${var.subnet_id}"
user_data = "${data.template_file.init.rendered}"
tags{
Name="ec2-uw2-np-sensu-01"
}
}

Expected Behavior

What should have happened?

user data we have mentioned to install amazon-ssm-agent and docker, using docker commands we are pulling some images and creating container , it is not taking user_data file.

Actual Behavior

What actually happened?
instance getting created but user_data is not getting picked

Steps to Reproduce

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

  1. terraform apply

Documentation: Cloud-init config template example needed

This issue was originally opened by @bigmyx as hashicorp/terraform#8694. It was migrated here as part of the provider split. The original body of the issue is below.


Hi,
In the following page there is a example of using a multipart data sources.
Also, there is a mention

The order of the parts is maintained in the configuration is maintained in the rendered template.

Can you please provide init.tpl file example?

In general, I would like to use one template file with the user data YAML and the user cloud-init Bash scripts.

Appreciate you help!

Provider cannot be migrated to terraform-plugin-sdk as it uses `lang` pkg directly

This provider uses the lang package directly, which is an internal package in terraform-plugin-sdk, and can thus not be migrated.

[lorbus@localhost terraform-provider-template]$ tf-sdk-migrator check
Checking Go runtime version ...
Go version 1.13.5: OK.
Checking whether provider uses Go modules...
Go modules in use: OK.
Checking version of github.com/hashicorp/terraform-plugin-sdk to determine if provider was already migrated...
Checking version of github.com/hashicorp/terraform used in provider...
Terraform version does not satisfy constraint >=0.12.7. Found Terraform version: 0.12.0-alpha4.0.20190424121927-9327eedb0417
Checking whether provider uses deprecated SDK packages or identifiers...
Deprecated SDK packages in use:
 * github.com/hashicorp/terraform/lang

Some constraints not satisfied. Please resolve these before migrating to the new SDK.

[regression] provider-template fails rendering when template file has % in the content starting from v2.0.0

Hi there,

Terraform Version

terraform version : 0.11.14

Affected Resource(s)

  • template_file since v2.0.0

Terraform Configuration Files

main.tf

data "template_file" "file" {
  template = "${file("${path.module}/file.tpl")}"
  vars = {
    name = "foo"
  }
}

output "rendered_file" {
  value = "${data.template_file.file.rendered}"
}

file.tpl

hello ${name},
%{bar}

Debug Output

data.template_file.file: Refreshing state...

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

* data.template_file.file: 1 error(s) occurred:

* data.template_file.file: data.template_file.file: failed to render : <template_file>:2,3-6: Invalid template control keyword; "bar" is not a valid template control keyword. Did you mean "for"?

Expected Behavior

The apply should render the data.template_file.file.rendered value correctly as follows:

rendered_file = hello foo,
%{bar}

Actual Behavior

generating an error using terraform-provider-template v2.0.0 and above, but working fine in v1.0.0
* data.template_file.file: data.template_file.file: failed to render : <template_file>:2,3-6: Invalid template control keyword; "bar" is not a valid template control keyword. Did you mean "for"?

Steps to Reproduce

  1. terraform init && terraform apply

Passing List as Template Variables

This issue was originally opened by @geek876 as hashicorp/terraform#9368. It was migrated here as a result of the provider split. The original body of the issue is below.


I want to render a template as below (effectively create an AWS Policy)

{
  "Version": "2012-10-17",
  "Statement": [
    {
       ...
       ...
      },
      "Action": "ec2:*",
      "Resource": "xxxx*"
    },
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "*"
      },
      "Action": "ec2:*",
      "Resource": "xxx/*",
      "Condition": {
        "IpAddress": {
          "aws:SourceIp": [
            "x.x.x.x/24",
            ...
            ...
            "x.x.x.x/16"
          ]
        }
      }
    }
  ]
}

My Template file test.tpl is

{
  "Version": "2012-10-17",
  "Statement": [
    {
       ...
       ...
      },
      "Action": "ec2:*",
      "Resource": "xxxx*"
    },
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "*"
      },
      "Action": "ec2:*",
      "Resource": "xxx/*",
      "Condition": {
        "IpAddress": {
          "aws:SourceIp": [${whitelist_ips}]
        }
      }
    }
  ]
}

How do I pass ${whitelist_ips} as list to template when I render it ?

I tried the usual way as below but it gives me template parse error

data "template_file" "x" {
  template = "${file("test.tpl")}"

  vars {
    whitelist_ips = [ "${split(",", var.allow_list}" ]
  }
}

My use case is that I don't want to hard-code the IPs within access policy and want to provide a way to pass it as a variable like

variable "allow_list" { default = "x.x.x.x/20,y.y.y/10" }

Terraform template creating the wrong type of numbers

Terraform Version

0.11.7
provider.template >= 2.0.0

Affected Resource(s)

template_file

Terraform Configuration Files

variable "ttl" {
    default = "31536000"
}

resource "null_resource" "test" {
  triggers {
    foo = "${format("%v", data.external.timestamp.result.seconds)}"
    bar = "${format("%v", (var.ttl / 2))}"
  }
}

data "template_file" "number" {
    template = "$${time / cycle}"
    vars {
        time  = "${data.external.timestamp.result.seconds}"
        cycle = "${var.ttl / 2}"
    }
}

Output

  + module.super_ca.null_resource.test
      id:                     <computed>
      triggers.%:             "2"
      triggers.bar:           "15768000"
      triggers.foo:           "1562944382"

Debug Output

Panic Output

Expected Behavior

data.template_file must generate the integer number which changed every half of year, example 97, 97, 99, etc

triggers.do_upload: "99" => "99"

Actual Behavior

data.template_file getting for input two integer numbers, but when template rendered math operation processed like with float numbers, and produce float number.

triggers.do_upload:            "99.10943226788432267884322678843226788432267884322678843226788432267884322678843226788432267884322678843226788432267884322678843226788432267884322678843227" => "99.10952708016235413495687468290208016235413495687468290208016235413495687468290208016235413495687468290208016235413495687468290208016235413495687468290208" (forces new resource)

Steps to Reproduce

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

  1. terraform init
  2. terraform apply

Important Factoids

This is works as expected with Terraform provider template version prior to 2.0.0.

References

Release 2.0.0 changes handling of escaped dollar signs

Hi there,

tf template provider: 2.0
tf version: 0.11.10
tf aws provider: 1.55

E.g. in 1.0 , a template file with the line

instanceId=$$(curl -s "http://169.254.169.254/latest/dynamic/instance-identity/document" | jq -r ".instanceId")

^^ produced a rendered valid value instanceId=10.10.10.10 when the line was executed as bash script as the line was rendered as

instanceId=$(curl -s "http://169.254.169.254/latest/dynamic/instance-identity/document" | jq -r ".instanceId")

However, in 2.0, we get error:

syntax error near unexpected token `('

^ because $$ in the line above never gets replaced in the template and gets rendered as instanceId=$$(curl -s "http://169.254.169.254/latest/dynamic/instance-identity/document" | jq -r ".instanceId").

What do we need to do make sure the parsing succeed?

Thanks

json: cannot unmarshal object into Go value of type string // Show Inputs and Outputs of External Data Command

This issue was originally opened by @Miserlou as hashicorp/terraform#13991. It was migrated here as part of the provider split. The original body of the issue is below.


Terraform Version

Terraform v0.9.3

Affected Resource(s)

  • data.external

Terraform Configuration Files

data "external" "template" {
  program =  ["zappa", "template",  "-r", "'${aws_iam_role.iam_for_my_lambda.arn}'", "-l", "'${aws_lambda_function.my_lambda.arn}'", "--json"]
  depends_on = ["aws_lambda_function.my_lambda"]
}

Debug Output

* data.external.template: data.external.template: command "zappa" produced invalid JSON: json: cannot unmarshal object into Go value of type string

Expected Behavior

The error shows the command which was executed and the output of that command.

Actual Behavior

I receive no useful information about the arguments of the executed command, or the output which failed to be parsed to JSON.

I don't now if this is a "Terraform-can't-parse-valid-JSON" bug, or a "My-program-pooped-the-bed" bug, because the output has no useful information in it, which makes it a "Terraform should be more helpful here in the UX department" bug.

Steps to Reproduce

  1. Create a complex command.
  2. terraform apply

Important Factoids

Running the command manually in my terminal produces valid JSON.

parametrized terraform template

This issue was originally opened by @reda-dw as hashicorp/terraform#12956. It was migrated here as part of the provider split. The original body of the issue is below.


I have a terraform project to create a 99 virtual machines in Openstack i can not use cloud-init and i must modify the hostname of every machine

hostname.tplt :

sudo sed -i -e "s/debian[7-9]/${host_name}/g" /etc/hostname
sudo invoke-rc.d hostname.sh start

sudo sed -i -e "s/127\.0\.1\.1.*/127.0.1.1\t${host_name}.${domain_name} ${host_name}/g" /etc/hosts
sudo apt-get update && sudo apt-get -y install dbus && sudo hostnamectl set-hostname ${host_name}

part of main.tf :

data "template_file" "hostname_servers" {
  template = "${file("templates/hostname.tplt")}"

  vars {
    host_name   = "${format("%s-proxy-%02d", var.prefix_name, count.index+1)}"
    domain_name = "${var.domain_name}"
  }
}

Ressource

resource "openstack_compute_instance_v2" "proxy-instance" {
  count       = "${var.count_proxy}"
  name        = "${format("%s-proxy-%02d", var.prefix_name, count.index+1)}"
  image_name  = "${var.image}"
  flavor_name = "${var.flavor_proxy}"

  network {
    name = "${format("%s-%s", var.prefix_name, var.network_name)}"
  }

  connection {
    user = "${var.user}"
  }

  provisioner "remote-exec" {
    inline = [
      "${data.template_file.hostname_servers.rendered}"
    ]
  }
}

the use case : when i start a terraform plan it works for the proxy-instance resource but i need to do that for the 99 machines, i don't like to duplicate the templates data 99 times, and i don't know how to parammetrize the template to be able to apply for all the machines any idea please?

Rich template language

This issue was originally opened by @errordeveloper as hashicorp/terraform#1845. It was migrated here as part of the provider split. The original body of the issue is below.


As #1778 has provided a way of doing interpolation in files, next step would be to see whether there could be a richer language available from inside a template file.

Such language would help for generating provisioning data that could be passed to a provide as metadata for setting up VMs or basic configuration files to be uploaded to VMs.

Remove `filename` from `template_file`

The deprecation of filename from template_file was done nearly 2 years ago.

As far as I know there's no good way in the resource schemas to mandate one parameter over another so the normal practice is to set both as optional, add a ConflictsWith key to both parameter and add a Deprecated key to the old parameter.

Unfortunately this means we can't use validate/plan to check that things are properly set and in this case even applying the config won't error other than to provide an empty rendered output to whatever uses it.

Is there a deprecation policy for how long things should be kept around for? It would be good to see filename ditched in the 1.0 release of the provider and probably a sensible time to make a breaking change.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.