Terraform-provider-aws: Add ability to set default version of aws_launch_template

Created on 25 May 2018  ·  22Comments  ·  Source: hashicorp/terraform-provider-aws

Community Note

  • Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
  • Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
  • If you are interested in working on this issue or have submitted a pull request, please leave a comment

Description

When changes are made and applied to an aws_launch_template resource, a new version of the template is created. However, this doesn't update the default version of the template, which means that when it is applied without choosing a version, the new changes will not be used.

default_version and latest_version are both exported as attributes, but default_version isn't available to set in Terraform.

It can, however, be set via the AWS CLI - eg.

aws ec2 modify-launch-template --launch-template-id "lt-xxxxxxxxxx" --default-version "1" --region ap-southeast-2

New or Affected Resource(s)

Potential Terraform Configuration

resource "aws_launch_template" "foo" {

  ...

  # Mutually exclusive options:
  default_version        = 1
  update_default_version = true # Updates default_version to latest_version on terraform apply
}
enhancement servicec2

Most helpful comment

Hi Everyone! :wave:

Due to the significant community interest in support for this feature, we will be looking at merging existing contributions soon.

We appreciate all the contributions and feedback thus far.

Look out for support for this feature within the next few releases!

All 22 comments

Is there a way to set the latest computed version to be the Default value in resource aws_launch_template ?

I agree this is very critical. I want to use aws_launch_template because it provides the ability to provide a customer managed kms key in the ebs block device declaration, and aws_launch_configuration doesn't support that. However I ran into the issue described in this ticket, so until this fix is merged I have to instead create a new launch template every time a new build is committed by modifying the name field using the unique git hash of the build.

In case anyone got here for the same reason I did (Couldn't figure out how to get the newly deployed launch_template immediately functional with using only terraform), you can do this in your ASG:

launch_template {
name = "${aws_launch_template.data.name}"
version = "${aws_launch_template.data.latest_version}"
}

Which effectively ensures the ASG is pointing at the latest one you just deployed.
Doesn't matter what the default is if as long your ASG is pointed at the latest version you deploy in the same module.
I still thing this needs to be integrated though as there needs to be a way to set the default_version and somehow to set the default version to itself would be ideal.

Isn't this solved by doing

launch_template { name = "${aws_launch_template.data.name}" version = "$$Latest" }

Isn't this solved by doing

launch_template { name = "${aws_launch_template.data.name}" version = "$$Latest" }

@jasonrojas no it only changes the version that the ASG uses and it does not change the default version that the API will provide when called without a version specified.

So if you want to create a launch template and use it in many places you need to provide the version each time you call it. So the terraform launch_template code needs a set_default_version parameter.

You may not want the latest version but rather the version that is default which generally would be the known stable version.

If you load the launch_template in the aws console and view the version configuration settings there it will make more sense.

We have switched to using t3 instances, which require that we use launch_templates to configure the cpu_credits options. We've just learned that this bug causes a host of issues with our ability to rerun our terraform to change other resource types. I'm not sure if the language here is accurate or not, but changing the "latest" launch template version would mess up what our ASG uses. It does not appear based on the errors, that this is messing with default.

~ aws_launch_template.test_lt
latest_version: "8" => "0"
tag_specifications.0.tags.Terraform: "" => "true"
tag_specifications.0.tags.terraform: "true" => ""
tag_specifications.1.tags.Terraform: "" => "true"
tag_specifications.1.tags.terraform: "true" => ""

Error: aws_launch_template.test_lt: "latest_version": this field cannot be set

You should probably provide your code as it looks like your trying to set
latest_version rather than setting version to $$Latest which is not the
same thing. Latest_version is a data attribute only and not something you
can set whereas version is.

On Tue, Dec 18, 2018 at 6:15 Kayla Crowder notifications@github.com wrote:

We have switched to using t3 instances, which require that we use
launch_templates to configure the cpu_credits options. We've just learned
that this bug causes a host of issues with our ability to rerun our
terraform to change other resource types. I'm not sure if the language here
is accurate or not, but changing the "latest" launch template version would
mess up what our ASG uses. It does not appear based on the errors, that
this is messing with default.

~ aws_launch_template.test_lt
latest_version: "8" => "0"
tag_specifications.0.tags.Terraform: "" => "true"
tag_specifications.0.tags.terraform: "true" => ""
tag_specifications.1.tags.Terraform: "" => "true"
tag_specifications.1.tags.terraform: "true" => ""

Error: aws_launch_template.test_lt: "latest_version": this field cannot be
set


You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/terraform-providers/terraform-provider-aws/issues/4655#issuecomment-447964179,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AJd59sL3UkI_hrcqjqsMDbrcjFU25cgVks5u5-1YgaJpZM4UNU5p
.

@isaacegglestone I think you missed the point. Latest_version is being changed by the launch template, not default version. We are setting the ASG to use the $$Latest version, not the default version. Based on the language being used here, if the launch template changes the latest_version from 8 to 0, my ASG will then start using version 0, as it's marked $$Latest. That will break things, and I'm ok not being able to change the data attribute, but I'm not ok with it being changed on my behalf, errantly, if I can't set it myself. I didn't consent that to happen.

latest_version: "8" => "0" is only an issue with terraform displaying computed values during plan. In our case it will always say 0 in plan but actually update latest_version attribute correctly.

@kaylacrowder can you post your config? I've been using latest_version attribute in asg settings for some time without any issues.

@gordonbondon I'm not talking about the ASG settings, I'm talking about the Launch Template.

@kaylaCrowder have you verified in the AWS web console that latest_verison is
actually changed to zero?

if you are sure and have verified in the web console then definitely as
mentioned post your config/code so someone can try replicating it.

On Fri, Dec 28, 2018 at 3:16 Kayla Crowder notifications@github.com wrote:

@gordonbondon https://github.com/gordonbondon I'm not talking about the
ASG settings, I'm talking about the Launch Template.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/terraform-providers/terraform-provider-aws/issues/4655#issuecomment-450213187,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AJd59l0mAeXKeyk2Z0HsMTLHLRCBUxnAks5u9RyHgaJpZM4UNU5p
.

@isaacegglestone @gordonbondon I'm also facing this problem.

And after some digging, I found out it maybe is due to incorrect behavior when resource aws_launch_template how to handle ignore_changes in lifecycle block.

It's seems that resource aws_launch_template just not try to update the attrs in ignore_changes settings, but still want to create a new version.

And here is my configuration.

data "aws_ssm_parameter" "ecs_instance_ami" {
  name = "/aws/service/ecs/optimized-ami/amazon-linux/recommended/image_id"
}

resource "aws_launch_template" "ecs_instance" {
  name_prefix                          = "lt-test-ecs-instance-"
  instance_type                        = "${var.ecs_instance_types[0]}"
  image_id                             = "${data.aws_ssm_parameter.ecs_instance_ami.value}"
  instance_initiated_shutdown_behavior = "terminate"

  block_device_mappings {
    device_name = "/dev/xvdcz"

    ebs {
      volume_type           = "gp2"
      volume_size           = "40"
      delete_on_termination = true
      encrypted             = false
    }
  }

  credit_specification {
    cpu_credits = "standard"
  }

  monitoring {
    enabled = false
  }

  tag_specifications {
    resource_type = "instance"

    tags {
      Name = "test-ecs-instance"
    }
  }

  tag_specifications {
    resource_type = "instance"

    tags {
      HostGroup = "test"
    }
  }

  lifecycle {
    create_before_destroy = true
    ignore_changes        = ["image_id"]
  }
}

I tried with the follow code:

resource "aws_autoscaling_group" "service-asg" {

  name                          = "${aws_launch_template.service-lt.name}-asg"
  max_size                      = "${var.service_asg_max}"
  min_size                      = "${var.service_asg_min}"
  desired_capacity              = "${var.service_asg_desired}"

  # Launch Template          
  launch_template            = {
    id = "${aws_launch_template.service-lt.id}"
    version = "${aws_launch_template.service-lt.latest_version}"
    #version = "$$Latest"
    #version = "2"
  }

Now the ASG is update to point to the latest Launch Template. Same as the $$Latest but however the instances are not refreshed. Any good idea on how to trigger it?

@zioalex ASG will not update existing instances on launch template change. Same applies to launch configurations and mixed settings. You can try approach described here https://medium.com/@endofcake/using-terraform-for-zero-downtime-updates-of-an-auto-scaling-group-in-aws-60faca582664

@chrisLeeTW resource uses build-in terraform function GetChangedKeysPrefix
to check if any field has updated and updates lastest_version if true, so if it does not respect ignore_changes this might be a core bug.

Thanks @gordonbondon nice read. I will try the approach outlined there. I have a web service so no need to include a CloudFormation template in it.

I'm using a workaround when don't resolve this issue:

resource "null_resource" "default"{
    triggers = {
        launch_template_change = aws_launch_template.lt.latest_version
    }
    provisioner "local-exec" {
        command = "/usr/local/bin/aws --profile ${var.aws_profile} --region ${var.aws_region} ec2 modify-launch-template --launch-template-id ${aws_launch_template.lt.id} --default-version ${aws_launch_template.lt.latest_version}"
        interpreter = ["/bin/bash","-c"]
    }
}

Hi Everyone! :wave:

Due to the significant community interest in support for this feature, we will be looking at merging existing contributions soon.

We appreciate all the contributions and feedback thus far.

Look out for support for this feature within the next few releases!

This feature has been merged and will release with v2.70.0 of the Terraform AWS Provider, expected this Thursday.

is v2.70 out ?

This has been released in version 2.70.0 of the Terraform AWS provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading.

For further feature requests or bug reports with this functionality, please create a new GitHub issue following the template for triage. Thanks!

Hi @nagulvali, apologies for the delay! The newest version released this morning 😃

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 feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thanks!

Was this page helpful?
0 / 5 - 0 ratings