aws_launch_configuration userdata issue with aws provider 1.13.0

[mukund1989]

Terraform Version

0.10.6, 0.11.3, 0.11.5

AWS Provider Version

1.13.0

Affected Resource(s)

aws_autoscaling_group
aws_launch_configuration

Terraform Configuration Files

resource "aws_launch_configuration" "master" {
  name_prefix          = "master-${var.cluster}-"
  iam_instance_profile = "${aws_iam_instance_profile.master.name}"
  image_id             = "${var.ubuntu_ami}"
  instance_type        = "${lookup(var.instance_type, var.cluster_size)}"
  key_name             = "${coalesce(var.ssh_key_name, data.terraform_remote_state.vpc.ssh_key_name)}"

  user_data = "${data.template_cloudinit_config.master.rendered}"


  # Storage
  root_block_device {
    volume_size = "${var.root_disk_size}"
    volume_type = "gp2"
  }

  security_groups = [
    "${aws_security_group.master.id}",
  ]

  lifecycle {
    create_before_destroy = true
  }
}

resource "aws_autoscaling_group" "masters" {
  name = "master-${var.cluster}"

  default_cooldown          = 6
  desired_capacity          = "${var.instance_count}"
  max_size                  = "${var.instance_count}"
  min_size                  = "${var.instance_count}"
  health_check_grace_period = 3
  health_check_type         = "EC2"
  force_delete              = true
  launch_configuration      = "${aws_launch_configuration.master.name}"
  target_group_arns         = ["${aws_lb_target_group.master_ext_tg.arn}"]
  vpc_zone_identifier       = ["${values(data.terraform_remote_state.vpc.subnets_control_map)}"] 
}

for the launch config user_data I have a list of files that is base64 encoded

Debug Output

[ERROR] root.masters: eval: *terraform.EvalValidateResource, err: Warnings: []. Errors: [expected length of user_data to be in the range (0 - 16384), got H4sIAAAAAAAA.....<followed by a big string of encoded userdata>

Panic Output

Expected Behavior

A successful plan indicating the below resources to add:

module.masters.aws_launch_configuration.master
id:
associate_public_ip_address: "false"
ebs_block_device.#:
ebs_optimized:
enable_monitoring: "true"
iam_instance_profile: "master-aws-use1-xxxx-xxxx"
image_id: "ami-xxxx"
instance_type: "m4.xlarge"
key_name: "aws-use1-xxxx-xxxx"
name:
name_prefix: "master-aws-use1-xxxx-xxxx"
root_block_device.#: "1"
root_block_device.0.delete_on_termination: "true"
root_block_device.0.iops:
root_block_device.0.volume_size: "20"
root_block_device.0.volume_type: "gp2"
security_groups.#:
user_data: "a529126e049c3263f29b00637cd24eb1775c5d8e"

module.masters.aws_autoscaling_group.masters
id:
arn:
default_cooldown: "6"
desired_capacity: "3"
force_delete: "true"
health_check_grace_period: "3"
health_check_type: "EC2"
launch_configuration: "${aws_launch_configuration.master.name}"
load_balancers.#:
max_size: "3"
metrics_granularity: "1Minute"
min_size: "3"
name: "master-aws-use1-xxxx-xxxx"
protect_from_scale_in: "false"
target_group_arns.#:
vpc_zone_identifier.#: "4"
vpc_zone_identifier.1003057897: "subnet-xxxxxx"
vpc_zone_identifier.2931960226: "subnet-xxxxxx"
vpc_zone_identifier.3016417446: "subnet-xxxxxx"
vpc_zone_identifier.3107657178: "subnet-xxxxxx"
wait_for_capacity_timeout: "10m"

Actual Behavior

Error: Error running plan: 1 error(s) occurred:

• module.masters.aws_autoscaling_group.masters: 1 error(s) occurred:

• module.masters.aws_autoscaling_group.masters: Resource 'aws_launch_configuration.master' not found for variable 'aws_launch_configuration.master.name'

Steps to Reproduce

1. terraform plan on the above resource

Important Factoids

This error actually relates to hashicorp/terraform#13510

But the root of the problem is that 1.13.0 is erroring out at userdata for launch config.
The same userdata and same code worked fine for 1.11.0 and the only reason I moved to 1.13.0 was to get past the crash as reported in #3962

I filed bug #4056 yesterday and I was thrown in a totally different direction because of hashicorp/terraform#13510

[catsby]

Hey @mukund1989 ! How is data.template_cloudinit_config setup? By default it base64 encodes the contents in the rendering, but you can disable that:

# Render a multi-part cloudinit config making use of the part
# above, and other source files
data "template_cloudinit_config" "config" {
  gzip          = false
  base64_encode = false
}

• https://www.terraform.io/docs/providers/template/d/cloudinit_config.html

[mukund1989]

@catsby This is what my template_cloudinit_config looks like

data "template_cloudinit_config" "master" {
  gzip          = false
  base64_encode = false
  part {
    content_type = "text/cloud-config"
    content = <<EOF
#cloud-config

write_files:
  - path: /etc/kubernetes/kubeconfig.yaml
    encoding: b64
    content: |
      ${base64encode(data.template_file.kubeconfig.rendered)}
 - path: /etc/docker/daemon.json
.
.
.
.
....several other files
  
runcmd:
  - blah blah

final_message: "Everything is awesome!"
EOF
  }
}

I also tried with
gzip = false
base64_encode = false

but getting a

Errors: [expected length of user_data to be in the range (0 - 16384), got Content-Type: multipart/mixed; boundary="MIMEBOUNDARY"

[mukund1989]

@catsby I am also curious to know if anything changed on 1.11.0 of the aws provider. I did not have issue reported in #3962 a few weeks ago :(

[mukund1989]

@catsby I tried using older versions of the aws provider 1.8.0, 1.9.0 & 1.10.0
and all are showing the same symptoms of #3962

I am kinda stuck, 1.13 has userdata issues and older versions are crashing(which was not the case a few weeks ago). This is delaying our infrastructure deployment. Appreciate if you can point me to a workaround.

Thanks!

[cagriy]

We are getting Errors: [expected length of user_data to be in the range (0 - 16384) error when using 1.14.0 with the components using a blank user-data in their launch configurations. Had to fix version to 1.13.0 to resolve the problem as we use quite a few components which receive blank user-data.

[salvianreynaldi]

I get the Errors: [expected length of user_data to be in the range (1 - 16384) error, too, with aws provider 1.14.0
previously "" user_data worked, which make it an optional parameter for an autoscaling module

is this a permanent change or will it be reverted to the previous behaviour?

[mukund1989]

@catsby any update on this ? I continue to face the below issue with even TF 0.11.3 & aws provider 1.13

Errors: [expected length of user_data to be in the range (0 - 16384)

[evanstachowiak]

I'm experiencing this as well with TF 0.10.7 and aws provider 1.15.0. Even when user_data is not blank I'm getting the error:
expected length of user_data to be in the range (1 - 16384), got

[aaron-ballard-530]

I just received this error as well. I'm running provider.aws: version = "~> 1.25" Was this not merged in or is this something else? I've been able to apply changes all day and it just stopped working after an init. TF version is 0.11.7

[ghost]

I found that changing the userdata variable

variable "user_data" {
  type        = "string"
  description = "user data"
  default     = ""
}

to

variable "user_data" {
  type        = "string"
  description = "user data"
  default     = false
}

fixes the error.

[sampcoug]

I changed the user_data variable to the following but it crashed the EC2 Instance. I am running CoreOS-Stable 1911.4.0. The instance failed Instance Status Checks so I was not able to connect to it.
Any advise folks?

variable "user_data" { type = "string" description = "user data" default = false }

[alexandergunnarson]

I ran into this same issue. Turned out that the user data template was referring to an empty file. When I replaced "${data.template_file.<name>.rendered}" with a blank string, I got the much more helpful error expected length of user_data to be in the range (1 - 16384). This is running:

Terraform v0.11.13
+ provider.aws v2.8.0
+ provider.ignition v1.0.0
+ provider.null v2.1.0
+ provider.random v2.1.0
+ provider.template v2.1.0
+ provider.vault v1.7.0

[va3093]

For me the problem was that the amount of data being sent as user data was above the threshold. I reduced the size of my scripts and enabled gzip compresion and it worked.

[PabloCamino]

I am bumping into this as well and so far have found no alternative to get it to work. Compression is already enabled.

[github-actions]

Marking this issue as stale due to inactivity. This helps our maintainers find and focus on the active issues. If this issue receives no comments in the next 30 days it will automatically be closed. Maintainers can also remove the stale label.

If this issue was automatically closed and you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thank you!