cloudposse / terraform-aws-ec2-autoscale-group Goto Github PK

Describe the Bug

There is no current way to configure scale_in_protected_instances and standby_instances behavior from the instance_refresh stanza.

Expected Behavior

When setting scale_in_protected_instances and standby_instances values in the instance refresh properties this should change the value applied at the end to this properties.

Steps to Reproduce

Add scale_in_protected_instances and standby_instances values different than Ignore to the instance refresh stanza. This will not modified the desire outcome.

Screenshots

No response

Environment

No response

Additional Context

No response

The resource aws_autoscaling_group can have either a tags or tag value set.

tags is deprecated.

output.tf is currently outputing tags and it produces this error:

PR has been raised for this:

#105

launch_template_version is not being used anywhere

Describe the Bug

launch_template_version $Latest does not trigger instance refresh when user-data or launch_tempate is updated.

Expected Behavior

When launch_template is updated , the latest version should be picked up by Autoscaling group and it should trigger instance refresh

Steps to Reproduce

Steps to reproduce the behavior:

1. Update the user-data or instance type or AMI
2. run terraform apply
3. it should show the launchtemplate update
4. it updates the launch template but, does not trigger instance refresh

Environment (please complete the following information):

Anything that will help us triage the bug will help. Here are some ideas:

• OS: Amazon Linux2

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• chore(deps): update terraform cloudposse/dynamic-subnets/aws to v2.4.2

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

Would you please give an example for instance_market_options ?

According to https://www.terraform.io/docs/providers/aws/r/launch_template.html#market-options

  instance_market_options {
    market_type = "spot"
  }

should it be list or map?

It would be nice if we can provide a launch template name using the name argument instead of just the name_prefix.

https://www.terraform.io/docs/providers/aws/r/launch_template.html#name

Describe the Bug

I got the error attached below in the logs section, when using this module because it requires hashicorp/template. I checked and it doesn't seem like you use it anymore.

Expected Behavior

Initializing the module without any errors.

Steps to Reproduce

Steps to reproduce the behavior:

1. Create the file with the module at its newest version using the darwin_arm64 platform.
2. Try to run terraform init.

Logs

Error: Incompatible provider version
Provider registry.terraform.io/hashicorp/template v2.2.0 does not
have a package available for your current platform, darwin_arm64.

Environment (please complete the following information):

Anything that will help us triage the bug will help. Here are some ideas:

• OS: macOS Big Sur
• Version: 11.6

Would be nice to set a min and max but also set a desired_capacity in between.

https://www.terraform.io/docs/providers/aws/r/autoscaling_group.html#desired_capacity

Describe the Bug

Module terraform-aws-ec2-autoscale-group resource aws_autoscaling_group does not support
below arguments.

• desired_capacity

• max_instance_lifetime

Expected Behavior

Module terraform-aws-ec2-autoscale-group resource aws_autoscaling_group should support below arguments via variables desired_capacity and max_instance_lifetime respectively.

• desired_capacity

• max_instance_lifetime

I will be happy to submit a PR to support mentioned arguments unless they are left out intentionally.

My general thoughts are that it should include the following resources:

• launch config
• autoscaling group
• security group
• dns record
• iam instance profile
• iam role
• elb (w/ variable for enabled)
• eip (w/ variable for enabled)

Variables:

• min/max size
• enabled
• volume size
• vpc id
• user data script var (this would need to be a path using ${path.module} syntax in local module)
• elb enabled/disabled
• eip enabled/disabled
• dns zone id
• security groups

There is an error with this repository's Renovate configuration that needs to be fixed. As a precaution, Renovate will stop PRs until it is resolved.

Error type: undefined. Note: this is a nested preset so please contact the preset author if you are unable to fix it yourself.

Describe the Bug

Module has variables scale_up_policy_type and scale_down_policy_type. According to documentation they support all values allowed in autoscaling_policy tf resource namely SimpleScaling, StepScaling and TargetTrackingScaling. On the other hand implementation of scaling policies does not contain blocks step_adjustments and target_tracking_configuration which are necessary to use StepScaling or TargetTrackingScaling respectively. This means that effectively only SimpleScaling is available.

Expected Behavior

Option A - support SimpleScaling

• Drop variables scale_*_policy_type and replace them with hardcoded SimpleScaling
• Explicit description of this in readme

Option B - full support for all three policies

Describe the Bug

What

The variable instance_initiated_shutdown_behavior should be set to null as it's also not allowed in the Launch Template when used for an EC2 Auto Scaling group

References

• #117

Expected Behavior

Probably we need to remove instance_initiated_shutdown_behavior

Steps to Reproduce

Screenshots

No response

Environment

No response

Additional Context

No response

what

• Add example invocation

why

• We need this so we can soon enable automated continuous integration testing of module

Found a bug? Maybe our Slack Community can help.

Describe the Bug

    {
      device_name  = "/dev/sda1"
      no_device    = "false"
      virtual_name = "root"
      ebs = {
        encrypted             = true
        volume_size           = 200
        delete_on_termination = true
        iops                  = null
        kms_key_id            = null
        snapshot_id           = null
        volume_type           = "standard"
      }
    }
  ]

When you run this, you get a

│ Error: creating Auto Scaling Group (moomoo-20220804165621917300000002): ValidationError: You must use a valid fully-formed launch template. The parameter iops is not supported for standard volumes.
│ 	status code: 400, request id: 529d3cad-0c92-4cbc-9d8e-a34d8e864ba8
│
│   with aws_autoscaling_group.default[0],
│   on main.tf line 143, in resource "aws_autoscaling_group" "default":
│  143: resource "aws_autoscaling_group" "default" {
│

Expected Behavior

I dont know if this is supported with gp2 as well, as when i swap out "standard" for "gp2" and set iops to null, I still get the same error. If I omit the IOPS flag, this module says it is required.

Describe the Bug

Use of deprecated tags attribute on the aws_autoscaling_group.default resource.

│ Warning: Argument is deprecated
│ 
│   with module.consul_server_fleet.aws_autoscaling_group.default,
│   on .terraform/modules/server_fleet/main.tf line 244, in resource "aws_autoscaling_group" "default":
│  244:   tags = flatten([
│  245:     for key in keys(module.this.tags) :
│  246:     {
│  247:       key                 = key
│  248:       value               = module.this.tags[key]
│  249:       propagate_at_launch = true
│  250:     }
│  251:   ])
│ 
│ Use tag instead

Expected Behavior

Code should be adjusted to the new provider version.

Environment:

Anything that will help us triage the bug will help. Here are some ideas:

• $ uname -a: Linux 5.15.23-2-lts #1 SMP Tue, 15 Feb 2022 12:04:53 +0000 x86_64 GNU/Linux
• Version: 0.30.0
• AWS provider: 4.2.0

https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/autoscaling_group#tag

Found a bug? Maybe our Slack Community can help.

Describe the Bug

Existing ASG with tags have this error The argument "tag.4.value" is required, but no definition was found. after upgrading to version 0.31.1. Can only do terraform apply if tags are removed.
(Changes from this PR #95)

Expected Behavior

Expected existing resources to have no change when upgrading from 0.31.0 to 0.31.1

Steps to Reproduce

Steps to reproduce the behavior:

1. Create ASG resources from module cloudposse/ec2-autoscale-group/aws version 0.31.0
2. Updating module version to 0.31.1
3. Run terraform plan
4. See error

Error: Missing required argument
│ 
│   with module.go_translate.module.autoscale_group.aws_autoscaling_group.default[0],
│   on .terraform/modules/go_translate.autoscale_group/main.tf line 144, in resource "aws_autoscaling_group" "default":
│  144: resource "aws_autoscaling_group" "default" {
│ 
│ The argument "tag.4.value" is required, but no definition was found.
╵

Anything that will help us triage the bug will help. Here are some ideas:

• OS: [e.g. Linux, OSX, WSL, etc] OSX
• Version [e.g. 10.15] 12.2

• I tested your samples.
  But I encountered "terraform crash"

• I upload crash log.
  Could you check it please?
  https://gist.github.com/sanggiChoi/e25d85fbf5dfc85bd04c6e0ff945fdbf

Thanks.

Describe the Feature

For some time AWS allows to enable instance tags in metadata through:

  metadata_options {
    instance_metadata_tags = "enabled"
  }

See: https://aws.amazon.com/about-aws/whats-new/2022/01/instance-tags-amazon-ec2-instance-metadata-service/

Expected Behavior

Ability to enable instance_metadata_tags

Use Case

This is very hand for setting up a hostname from "Tag:Name" and other useful automations without AWS SDK installed e.g. following cloud init example old way:

set -x
r=$(exec curl -s http://169.254.169.254/latest/dynamic/instance-identity/document/ | jq -r .region)
i=$(exec curl -s http://169.254.169.254/latest/dynamic/instance-identity/document/ | jq -r .instanceId)
n=$(aws ec2 --region "$r" describe-instances --instance-ids "$i" | jq -r '.Reservations[].Instances[].Tags[] | select(.Key=="Name") | .Value')
if [[ -n "$n" ]]; then
    hostnamectl set-hostname --static "$n" 
fi

Simpler way:

set -x

n=$(curl http://169.254.169.254/latest/meta-data/tags/instance)
if [[ -n "$n" ]]; then
    hostnamectl set-hostname --static "$n" 
fi

Describe Ideal Solution

Just add it to the TF ;)

Alternatives Considered

There are no alternatives.

Found a bug? Maybe our Slack Community can help.

Describe the Bug

Object type attributes are not marked as optional when they are. It requires to set them to null explicitly.
For instance:

  mixed_instances_policy = {
    instances_distribution = {
      on_demand_allocation_strategy            = null
      on_demand_base_capacity                  = null
      spot_allocation_strategy                 = null
      spot_instance_pools                      = null
      spot_max_price                           = null
      on_demand_percentage_above_base_capacity = 20
    }
    override = [{
      instance_type     = var.ec2_instance_type
      weighted_capacity = null
    }]
  }

Expected Behavior

It should be possible to set it like this

  mixed_instances_policy = {
    instances_distribution = {
      on_demand_percentage_above_base_capacity = 20
    }
    override = [{
      instance_type     = var.ec2_instance_type
    }]
  }

Should be possible with TF starting 0.14 https://www.terraform.io/docs/language/expressions/type-constraints.html

Environment (please complete the following information):

Anything that will help us triage the bug will help. Here are some ideas:

• OS: Linux
• Version 0.28.1

Have a question? Please checkout our Slack Community or visit our Slack Archive.

Describe the Feature (Use Case)

I would like to fire EC2 instances based on instance requirements rather than having to specify a given instance type. For example, I want a bare minimum of 4 vCPU with 16 GiBs of RAM across my EC2 instance fleet.

Expected Behavior

I don't mind if we implemented it in a non-backwards compatible way. Although, I believe it's doable. THe instance_requirements variable would clash if configured alongside the instance_type

Describe Ideal Solution

The TF provider has support for all of these elements:

https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/launch_template#instance-requirements

In fact, the OSS Terraform-modules equivalent leverages a similar approach

https://github.com/terraform-aws-modules/terraform-aws-autoscaling/blob/master/main.tf#L160

Alternatives Considered

Stop using this module to create ASGs and rely on other partners or a self-baked one.

Additional Context

N/A

Describe the Feature

AWS Provider 3.x has been released.

Expected Behavior

This module supports the new provider version.

Terraform AWS Provider Version 3 Upgrade Guide

Found a bug? Maybe our Slack Community can help.

Describe the Bug

When iam_instance_profile_name is set to an empty variable. The terraform apply always results in new changes to be applied.

Expected Behavior

If the iam_instance_profile_name is set to empty it should not result in any new terraform changes.

Steps to Reproduce

Steps to reproduce the behavior:

1. Specify empty iam_instance_profile_name as {}
2. Do a terraform apply

Screenshots

  ~ resource "aws_launch_template" "default" {
        id                                   = "xxx-sd"
      ~ latest_version                       = 2 -> (known after apply)
        name                                 = "test"
        tags                                 = {
            "Environment" = "us-west-2"
            "Name"        = "test"
            "Namespace"   = "test"
        }

      + iam_instance_profile {} <--
    }

Environment (please complete the following information):

Anything that will help us triage the bug will help. Here are some ideas:

• OS: [e.g. Linux, OSX, WSL, etc]
• Version [e.g. 10.15]

Additional Context

Add any other context about the problem here.

Found a bug? Maybe our Slack Community can help.

Describe the Bug

When the automatic scaling increases the number of instances and we execute the code from desired_capacity, the number of instances will be set according to the value of desired_capacity, ignoring the current alarm state. If we do not specify desired_capacity, it will be set to the minimum value anyway.

Expected Behavior

When the current number of instances is 2 and we execute the code without desired_capacity , 2 instances will still work.

Steps to Reproduce

Steps to reproduce the behavior:

1. Setup ASG with alarm
2. Trigger allarb (now asg should have 2 insatnce)
3. Apply changes (example change ami)
4. See error

Screenshots

If applicable, add screenshots or logs to help explain your problem.

Environment (please complete the following information):

Anything that will help us triage the bug will help. Here are some ideas:

• OS: linux
• Version 0.22.0

Additional Context

https://github.com/cloudposse/terraform-aws-ec2-autoscale-group/blob/master/main.tf#L141

https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/autoscaling_group#desired_capacity

https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/autoscaling_group#waiting-for-capacity

Have a question? Please checkout our Slack Community or visit our Slack Archive.

Describe the Feature

I'll be using this module to create an ASG where the instances will be joining an ECS cluster.
It would be nice to have the ability to create a cluster within this module, and if that option is used, then to add to the user_data and join the ECS cluster from there

Expected Behavior

A flag var.create_ecs_cluster which will then also create an ECS cluster with the same naming as the ASG, and will also add lines to the user_data of the instances in this ASG that joins them to the ECS cluster.

Alternatives Considered

• I can wrap this module with a parent module that adds the resource for ECS cluster and adds to the user_data.
• I can use a separate module which just creates the single resource ECS cluster.

Additional Context

I am using Terragrunt so my infrastructure is based on modules, it is somewhat painful to create single resources in my architecture pattern. That's why ideally it could be done in this module.

The error I get when using terraform 0.15.0

│ Error: Error in function call
│
│   on .terraform/modules/redacted.ecs.autoscale_group/main.tf line 14, in resource "aws_launch_template" "default":
│   14:         for_each = flatten(list(lookup(block_device_mappings.value, "ebs", [])))
│     ├────────────────
│     │ block_device_mappings.value will be known only after apply
│
│ Call to function "list" failed: the "list" function was deprecated in Terraform v0.12 and is no longer available; use tolist([ ... ]) syntax to write a literal list.
╵

The type definition in the variables.tf file seems to stop you being able to use simple setups

  block_device_mappings = [
    {
      device_name = "/dev/sda1"
      no_device    = false
      virtual_name = "root"
      ebs = {
        delete_on_termination = true
        volume_size           = 22
      }
    }
  ]

Fails with

Error: Invalid value for module argument

  on main.tf line 133, in module "autoscale_group":
 133:   block_device_mappings = [
 134:     {
 135:       device_name = "/dev/sda1"
 136:       no_device    = false
 137:       virtual_name = "root"
 138:       ebs = {
 139:         delete_on_termination = true
 140:         volume_size           = 22
 141:       }
 142:     }
 143:   ]

The given value is not suitable for child module variable
"block_device_mappings" defined at
.terraform/modules/autoscale_group/variables.tf:108,1-33: element 0: attribute
"ebs": attributes "encrypted", "iops", "kms_key_id", "snapshot_id", and
"volume_type" are required.

Which was after adding

      no_device    = false
      virtual_name = "root"

as it wouldnt work without those either.

Removing the type restrictions from the vars allows it to work as expected

  type = list(object({
    device_name  = string
    no_device    = bool
    virtual_name = string
    ebs = object({
      delete_on_termination = bool
      encrypted             = bool
      iops                  = number
      kms_key_id            = string
      snapshot_id           = string
      volume_size           = number
      volume_type           = string
    })
  }))

Found a bug? Maybe our Slack Community can help.

Describe the Bug

Missing throughput in block_device_mappings. https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/launch_template#throughput

Expected Behavior

A clear and concise description of what you expected to happen.

Steps to Reproduce

Steps to reproduce the behavior:

1. Go to '...'
2. Run '....'
3. Enter '....'
4. See error

Screenshots

If applicable, add screenshots or logs to help explain your problem.

Environment (please complete the following information):

Anything that will help us triage the bug will help. Here are some ideas:

• OS: [e.g. Linux, OSX, WSL, etc]
• Version [e.g. 10.15]

Additional Context

Add any other context about the problem here.

Describe the Feature

I'd like to be able to use https://github.com/meltwater/terraform-aws-asg-dns-handler and this requires being able to specify lifecycle hooks to the autoscale group.

Expected Behavior

I can add this module, define the hooks, and generate hostnames for my autoscale groups.

Use Case

I need hostnames or predictable networking for my autoscale groups.

Describe Ideal Solution

I can add a few lines to my main.tf and this will work.

Alternatives Considered

I've been experimenting with this all yesterday and haven't gotten anything working.

Additional Context

Recipe I'm working on is here: https://github.com/converged-computing/flux-terraform-ami/pull/1/files#diff-6e45d26e502f88302f69c4c196babd8939186d9cd298f94caca283c128a2d186