Terraform: 0.9.7 breaks provisioners using template_file with "Must provide one of 'content' or 'source'"

[sjwl]

terraform plan fails when using a template_file in a file provisioner

Terraform Version

0.9.7

Affected Resource(s)

All

Terraform Configuration Files

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

resource "test_resource" "test" {
  required = "${count.index}"
  required_map {
    key1 = "value1"
    key2 = "value2"
  }

  provisioner "file" {
    content = "${data.template_file.test.rendered}"
    destination = "foo"
  }
}

Expected Behavior

Plan should succeed with no error. here is a sample output when using terraform 0.9.6

$GOPATH/bin/terraform_0.9.6 plan
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but will not be
persisted to local or remote state storage.

data.template_file.test: Refreshing state...
The Terraform execution plan has been generated and is shown below.
Resources are shown in alphabetical order for quick scanning. Green resources
will be created (or destroyed and then created if an existing resource
exists), yellow resources are being changed in-place, and red resources
will be destroyed. Cyan entries are data sources to be read.

Note: You didn't specify an "-out" parameter to save this plan, so when
"apply" is called, Terraform can't guarantee this is what will execute.

+ test_resource.test
    computed_from_required:       "<computed>"
    computed_list.#:              "<computed>"
    computed_map.%:               "<computed>"
    computed_read_only:           "<computed>"
    computed_read_only_force_new: "<computed>"
    computed_set.#:               "<computed>"
    optional_computed_force_new:  "<computed>"
    optional_computed_map.%:      "<computed>"
    required:                     "0"
    required_map.%:               "2"
    required_map.key1:            "value1"
    required_map.key2:            "value2"


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

Actual Behavior

using 0.9.7...

terraform plan                  
1 error(s) occurred:

* test_resource.test: Must provide one of 'content' or 'source'

Steps to Reproduce

1. terraform plan

[akaspin]

Same issue on 0.9.8.

[odedpriva]

This is a blocking issue for using terraform in production, at least in my case.
I couldn't revert back to 0.9.6 due to this restriction:

Terraform doesn't allow running any operations against a state
that was written by a future Terraform version. The state is
reporting it is written by Terraform '0.9.8'.

Please run at least that version of Terraform to continue.

I would really appreciate if anyone from the terraform team could suggest a temp workaround for this issue.

[jaydub]

This is actually failing on any interpolation in the content value of (at least) file provisioner resources.

[denisbr]

I get the same error on 0.9.8, but I don't think it requires to use a template_file even, simply using a file gives me the same error, going back to 0.9.6 with no changes to the configuration.

[akaspin]

Any news? Right now current release (0.9.8) is broken.

[onorua]

I've done a bisect, and it seems it got broken in the following commit: https://github.com/hashicorp/terraform/commit/f5449a62e090b105a826b73c49523a232ce23132
Looking for way to fix it.

[svanharmelen]

I'm at the HashiDays in London today, so don't have a workspace nearby. But will have a look at this first thing tomorrow morning and make sure this is fixed asap.

As for using an older version of TF with a newer state file. This indeed is not adviced, but the TF changes between 0.9.8 and 0.9.6 do not include any state structure changes. So you should be able to manually edit the version in your state file.

Of course make sure you backup or copy your TF files first, run a refresh and then a plan to double check that all is good before moving on.

[spanktar]

FWIW, also getting this from aws_instance resources:

* aws_instance.bastion: Must provide one of 'content' or 'source'

The resource:

resource "aws_instance" "bastion" {
  ami               = "${lookup(var.ami, "${var.aws_region}_amz_hvm")}"
  instance_type     = "${lookup(var.instance_type, "bastion")}"
  key_name          = "${var.key_name}"
  monitoring        = true
  source_dest_check = false
  subnet_id         = "${aws_subnet.subnet_dmz.id}"

  vpc_security_group_ids = [
    "${aws_security_group.vsg_bastion.id}",
  ]

  provisioner "file" {
    content     = "${data.template_file.tpl_profile_custom.rendered}"
    destination = "/tmp/custom.sh"
  }

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

  connection {
    host        = "${aws_instance.bastion.public_ip}"
    private_key = "${file("${var.local_ssh_key_path}")}"
    user        = "${var.ssh_user}"
  }

  tags {
    Environment = "${var.environment}"
    GitHash     = "${var.git_hash}"
    Name        = "${var.environment}_bastion_server"
    Version     = "${var.version}"
  }
}

[onorua]

@spanktar do you mind showing complete configuration? From what I saw, the mentioned commit is affecting file and chef provisioners, aws_instance might be something different or may be the same.

[svanharmelen]

This one is only due to an issue with the file provisioner. The Chef provisioner is an isolated issue.

[jasonrojas]

I'm seeing this with the file provisioner as well.

[serialx]

Why is this issue closed? I can verify issue in 0.9.8.

[mprimeaux]

I believe this was closed since the related PR passed and thus the fix is in 0.9.9. See https://github.com/hashicorp/terraform/pull/15273.

But I'm glad you've asked. It would be good to know definitively.

[serialx]

Confirmed, works on HEAD. Thank you @mprimeaux !

[orlando]

Given the @odedpriva comment, if you are looking to downgrade your Terraform version from 0.9.8 to 0.9.6 to get around this issue and have remote state enabled you can do the following.

• Install Terraform 0.9.6
• Download your remote state file and change the version from 0.9.8 to 0.9.6
  
• Upload that file to your remote state (in my case S3)
• Run terraform plan

This should work without problems given @svanharmelen comment https://github.com/hashicorp/terraform/issues/15177#issuecomment-307800618, there are not structural changes in the state between 0.9.6 and 0.9.8 versions

[spanktar]

Just a handy note here re: downgrading, I use this tool to manage multiple TF versions on MacOS using Homebrew with ease:

https://github.com/Yleisradio/homebrew-terraforms

@orlando @odedpriva

[vikas027]

@spanktar brew lets you switch versions easily brew switch terraform <terraform_version>

[orlando]

Btw this is fixed on the latest version just upgrade and it should work

[hashibot[bot]]

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.