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

template_file with count causes instances to be rebuild on increase #5736

Closed
MansM opened this issue Mar 20, 2016 · 3 comments
Closed

template_file with count causes instances to be rebuild on increase #5736

MansM opened this issue Mar 20, 2016 · 3 comments

Comments

@MansM
Copy link

MansM commented Mar 20, 2016

resource "template_file" "masters_cloud_init" {
  count = "${var.mastercount}"
  template = "${file("master.yaml.tpl")}"
  vars {
    hostname = "master${count.index+1}"
  }
}


resource "aws_instance" "kubemaster" {
  count = "${var.mastercount}"
  ami = "${lookup(var.amis, var.region)}"
  instance_type = "t2.micro"
  key_name = "mans"
  vpc_security_group_ids = ["${aws_security_group.kubernetes.id}"]
  subnet_id = "${aws_subnet.kubernetes.id}"
  tags = {
      Role = "kubemaster"
      Env = "dev"

  }
  user_data = "${element(template_file.masters_cloud_init.*.rendered, count.index)}"
  provisioner "remote-exec" {
    inline = [
      "ls -l"
    ]
  }
}

when I increase var.mastercount from 2 to 3, all 3 the instances are getting recreated.

-/+ aws_instance.kubemaster.0
user_data:                        "1974e36c46d425037f2cd7e66f793030fc72cfda" => "66f502e5ff78bee2ebd70b6e04be1c6cb5d78a31" (forces new resource)

-/+ aws_instance.kubemaster.1
    user_data:                        "81e28c58224841c9d6c5c6f6d91163ed9158bd80" => "66f502e5ff78bee2ebd70b6e04be1c6cb5d78a31" (forces new resource)

+ aws_instance.kubemaster.2
    user_data:                        "" => "66f502e5ff78bee2ebd70b6e04be1c6cb5d78a31"

Terraform v0.6.13

@Fodoj
Copy link

Fodoj commented Apr 11, 2016

My favorit bug so far. Was reported so may times already in November 2015: #3885 Shame it still gets zero attention from core team

@apparentlymart
Copy link
Contributor

Hi @MansM,

As @Fodoj mentioned this is an implication of the bug being discussed in #3449. This is not being quickly addressed because it represents a tricky architectural challenge for Terraform. To be specific, the diffing code sees that all of the rendered templates are being used in user_data and thus applies the "computed" state to the result, even though as users we know that element will actually ignore all but a single item from that set. To fix this fully-generally, the diffing code needs a special case for the element function.

However, for this particular case where it's multiple template_file resources you're trying to use, it's likely that this would be resolved by a different architectural change #4169, which would recast template_file as a "data source" rather than a resource, and that means its rendered result would be available immediately on the initial plan, rather than having to wait until this pseudo-resource is "created". This latter issue is being worked on over in #4961, and is planned to be included in the 0.7 minor release along with some other trickier new capabilities.

A potential workaround for this in the mean time is to use the -target argument to terraform apply to force Terraform to update your template_file resources in isolation first, and then subsequently run terraform plan again without a -target to update the aws_instance resources based on the newly-rendered templates. I think something like the following should get your new template_file rendered so that Terraform will not treat it as "computed" on subsequent runs:

$ terraform apply -target=template_file.masters_cloud_init

For now I'm going to close this issue to consolidate discussions in #3449 and #4169 respectively. Thanks for taking the time to file this and I'm sorry that this case is so tricky right now.

@ghost
Copy link

ghost commented Apr 26, 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.

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

No branches or pull requests

4 participants