Terraform-provider-aws: aws_autoscaling_group bug - fail to set OnDemandBaseCapacity value to zero

Created on 28 Jan 2019  ·  14Comments  ·  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

Terraform Version

Terraform v0.11.10

  • provider.aws v1.57.0
  • provider.template v2.0.0

Affected Resource(s)

  • aws_autoscaling_group

Terraform Configuration Files

provider "aws" {
  region  = "us-west-1"
  version = "~> 1.51"
}


resource "aws_launch_template" "lt" {
  name_prefix = "LT-spot-test"
  image_id = "${var.image_id}"
  instance_type = "t2.large"
  key_name = "${var.key_name}"

  vpc_security_group_ids = [
    "${var.security_groups}",
  ]

  iam_instance_profile {
    arn = "${var.iam_instance_profile}"
  }

  lifecycle {
    create_before_destroy = true
  }
}

resource "aws_autoscaling_group" "asg" {
  name_prefix      = "ASG-spot-test"
  max_size         = "${var.size}"
  min_size         = "${var.size}"
  desired_capacity = "${var.size}"
  target_group_arns = []
  health_check_type = "EC2"
  wait_for_capacity_timeout = "2m"   # 6 minutes is the default
  wait_for_elb_capacity = "${var.size > 0 ? var.size : 0}"
  health_check_grace_period = "300"

  vpc_zone_identifier = [
    "${var.vpc_zone_identifier}"
  ]

  mixed_instances_policy {
    instances_distribution {
      on_demand_base_capacity                  = "${var.size}"
      on_demand_percentage_above_base_capacity = 0
    }

    launch_template {
      launch_template_specification {
        launch_template_id = "${aws_launch_template.lt.id}"
        version            = "${aws_launch_template.lt.latest_version}"
      }

      override {
        instance_type = "t2.large"
      }

      override {
        instance_type = "t2.xlarge"
      }
    }
  }

  lifecycle {
    create_before_destroy = true
  }
}

Debug Output

Panic Output

Expected Behavior


When setting ASG desired_capacity, max_size, min_size and on_demand_base_capacity from "2" to "0" I would expect this work.

Actual Behavior


Got the following output & error:

aws_autoscaling_group.asg: Modifying... (ID: ASG-spot-test20190128172151691300000003)
desired_capacity: "2" => "0"
max_size: "2" => "0"
min_size: "2" => "0"
mixed_instances_policy.0.instances_distribution.0.on_demand_base_capacity: "2" => "0"
wait_for_elb_capacity: "2" => "0"

Error: Error applying plan:

1 error(s) occurred:

  • aws_autoscaling_group.asg: 1 error(s) occurred:

  • aws_autoscaling_group.asg: Error updating Autoscaling group: ValidationError: Max bound, 0, must be greater than or equal to OnDemandBaseCapacity, 2.
    status code: 400, request id: aa94c480-2321-11e9-b6ea-799c575c4fd5

Steps to Reproduce

  1. terraform apply -var size=2
  2. terraform apply -var size=0

Important Factoids

References

  • #0000
bug servicautoscaling

Most helpful comment

I'm seeing a related issue with 2.6.0.

I have something like this :

resource "aws_autoscaling_group" "my_autoscaling_group" {
  name             = "my-asg"
  desired_capacity = "1"
  min_size         = "0"
  max_size         = "2"
    mixed_instances_policy {
    launch_template {
      launch_template_specification {
        launch_template_id = "${aws_launch_template.launch_template.id}"
        version            = "$Latest"
      }
    override {
        instance_type = "t2.small"
      }

      override {
        instance_type = "t2.large"
      }
  }
  instances_distribution {
      on_demand_base_capacity                  = "${var.on_demand_size}"
      on_demand_percentage_above_base_capacity = 0
    }
}

Originally, on_demand_size was set to 1. If I try to set it to 0, terraform doesn't detect any change in the plan and the apply is not changing anything either

All 14 comments

Pull request submitted: #7821

The fix for this has been merged and will release with version 2.1.0 of the Terraform AWS Provider, likely in the next day or so.

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

Hi @bflad,

I tested this in latest version (v2.2.0) and still have the same issue in the following scenario:

  1. terraform apply -var size=1 -var image_id=ami-093bd10d3d9013341
  2. terraform apply -var size=0 -var image_id=ami-0330ce7ce2f6ae44c

aws_autoscaling_group.asg: Modifying... (ID: ASG-spot-test20190320123311924800000003)
desired_capacity: "1" => "0"
max_size: "1" => "0"
min_size: "1" => "0"
mixed_instances_policy.0.launch_template.0.launch_template_specification.0.version: "5" => "6"
wait_for_elb_capacity: "1" => "0"

Error: Error applying plan:

1 error(s) occurred:

  • aws_autoscaling_group.asg: 1 error(s) occurred:

  • aws_autoscaling_group.asg: Error updating Autoscaling group: ValidationError: Max bound, 0, must be greater than or equal to OnDemandBaseCapacity, 1.
    status code: 400, request id: 3ffb09f6-4b0f-11e9-be5a-2dff37296df3

I noticed that the issue happens when:
max_size is to be changed from 1 to 0 and at the same time mixed_instances_policy.0.launch_template.0.launch_template_specification.0.version: is being changed as well (e.g. as a result of AMI ID change in the Launch Template.

Can you please re-open the issue?

Thanks,
Roy

Is your configuration different now than before? In the original report its showing this in the plan:

mixed_instances_policy.0.instances_distribution.0.on_demand_base_capacity: "2" => "0"

Which wouldn't have previously updated correctly before version 2.1.0 of the Terraform AWS Provider. Now however, your new output is not showing that update. Your mixed_instances_policy configuration block instances_distribution configuration block on_demand_base_capacity argument always needs to be less than or equal to the max_size according to the AutoScaling API rules. The updates to both max_size and mixed_instances_policy occur in the same UpdateAutoScalingGroup API call (at least in the case where the Error updating Autoscaling group error messaging is triggered) so this appears to be more of a configuration issue.

The original scenario was indeed resolved in 2.1.0.

However now it is still failing in another specific scenario where on_demand_base_capacity is originally equal to 1 (as well as the max_size) and both being changed to zero and at the same time the Launch Template version is also being changed.

This failure does not happen if the value of on_demand_base_capacity and max_size are being changed from 2 to zero.

I'm seeing a related issue with 2.6.0.

I have something like this :

resource "aws_autoscaling_group" "my_autoscaling_group" {
  name             = "my-asg"
  desired_capacity = "1"
  min_size         = "0"
  max_size         = "2"
    mixed_instances_policy {
    launch_template {
      launch_template_specification {
        launch_template_id = "${aws_launch_template.launch_template.id}"
        version            = "$Latest"
      }
    override {
        instance_type = "t2.small"
      }

      override {
        instance_type = "t2.large"
      }
  }
  instances_distribution {
      on_demand_base_capacity                  = "${var.on_demand_size}"
      on_demand_percentage_above_base_capacity = 0
    }
}

Originally, on_demand_size was set to 1. If I try to set it to 0, terraform doesn't detect any change in the plan and the apply is not changing anything either

I am still having this issue with provider 2.19

whenever i set the on_demand_base_capacity to 0 ( or not set it at all ) it actually get set to 1 in the plan / apply phase

setting it to anything > 1 works as expected

--EDIT

apparently ( from https://github.com/terraform-providers/terraform-provider-aws/issues/7938#issuecomment-484062626 ) my problem was that i was trying to change an already created ASG )

I can confirm, we had to delete the ASG itself by hand to have Terraform correctly re-create it with the changes made to instances_distribution.

I can confirm this issue still exist with provider aws v2.62.0.
When I set "on_demand_base_capacity" to 1, it is updated successfully.
When I set it back to 0, Terraform does not detect the change.
As a workaround if I set "on_demand_base_capacity" from 1 to 2 and then from 2 to 0, the change is detected and applied successfully.

looking into this more, it's seems this line here in the autoscaling_group resource's DiffSuppressFunc for the instances_distribution attribute affects the on_demand_capacity update from 1 -> 0 (and not 2 -> 0) https://github.com/terraform-providers/terraform-provider-aws/blob/47a7974e2458920595eaa56ca29c43d66a03ae11/aws/resource_aws_autoscaling_group.go#L100

While this pattern has been used for other schema.TypeList attributes, such that the values passed to a DiffSuppressFunc reference the count, it seems in this case of a nested List, the values passed to the DiffSuppressFunc are the values associated with attributes in the instances_distribution list, in this case e.g. on_demand_capacity, and are interpreted literally; thus, a value of "0" will cause the diff suppression

with this being said, we could remove the DiffSuppressFunc but be forced to adjust the attributes to Computed for example, or maybe add a DiffSuppressFunc per attribute in the List to disable drift detection, or perhaps there's a known workaround for this use case. I'll circle back here with updated findings/proposed fix.

The fix for this has been merged and will release with version 2.66.0 of the Terraform AWS Provider, expected in this week's release.

This has been released in version 2.66.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!

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