Terraform-provider-aws: Terraform can not validate empty IPv4 address with 2.65.0

Created on 5 Jun 2020  ·  23Comments  ·  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 other comments that do not add relevant new information or questions, 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.14 and Terraform AWS provider 2.65.0

Affected Resource(s)

  • aws_instance

Terraform Configuration Files

variable "private_ip" {
  default     = ""
  type        = "string"
  description = "Private IP address to associate with the instance in a VPC."
}
resource "aws_instance" "ec2_node" {
  private_ip = "${var.private_ip}"
}

Debug Output

Panic Output

Expected Behavior

should ignore when no IPv4 is provided

Actual Behavior

Error: module.x.aws_instance.ec2_node: expected private_ip to contain a valid IPv4 address, got:

Steps to Reproduce

  1. lockdown the provider to 2.65.0 and terraform plan

Important Factoids

References

  • #0000
bug regression servicec2

Most helpful comment

Facing the same issue with the new provider version 2.65.0.

As a workaround forcing the older version to be used:

terraform {
    required_providers {
    aws = "~> 2.64.0"
  }
}

All 23 comments

I'm facing same issue as of today.

$ terraform plan

Error: aws_instance.jump_host1: expected private_ip to contain a valid IPv4 address, got: 

My tf file contents

resource "aws_instance" "jump_host1" {
  ami                         = "ami-xxxxxxxxx"
  instance_type               = "t2.small"
  key_name                    = "xxx-key"
  source_dest_check           = false
  subnet_id                   = "${aws_subnet.edge_0.id}"
  private_ip                  = ""
  vpc_security_group_ids      = ["${aws_security_group.jump_host.id}","${aws_security_group.jump_host_test.id}"]
  associate_public_ip_address = true
  disable_api_termination     = false
  availability_zone           = "us-east-1a"

  root_block_device {
    volume_type = "gp2"
    volume_size = "32"
    delete_on_termination = true
  }

  tags {
    Name        = "auto10023652_jump_host1"
    Role        = "JUMP"
      Owner       = "[email protected]"
      Project     = "xxx"
      Env         = "qa"
      Component   = "xxxx"
      Team        = "xxxxx"
      Downtime    = "off"
  }

  connection {
      type = "ssh"
      user = "operations"
      private_key = "${file("xxxx.pem")}"
  }

  provisioner "file" {
      source = "/root/xxxx.pem"
      destination = "~/.ssh/yyyy.pem"
  }

  provisioner "file" {
      source = "resources/jump_host_bash_profile"
      destination = "~/.bash_profile"
  }

  provisioner "file" {
      source = "resources/env_eks"
      destination = "~/.env_eks"
  }


  lifecycle {
    ignore_changes = [
      "tags"
    ]
  }
}

I am facing same issue

$ terraform plan

Error: aws_instance.test1: expected private_ip to contain a valid IPv4 address, got:

Facing the same issue with the new provider version 2.65.0.

As a workaround forcing the older version to be used:

terraform {
    required_providers {
    aws = "~> 2.64.0"
  }
}

Same for me

Facing this issue while trying to create spot instances at my organisation :(

Seems an issue on latest version: https://github.com/terraform-providers/terraform-provider-aws/commit/1a1ddc5bae2513c9e8f9da63eb0c2292c8e76afd

Maybe related with this:* resource/aws_instance: Add plan time validation to volume_type(in ebs_block_device and root_block_device blocks), private_ip, ipv6_addresses, and tenancy [GH-13033]

So as workaround as @v3se said 2.64 also worked for me

Can confirm, 2.64.0 version of the provider is fine. But this change will very likely remain since validation function is totally legit. :)

As a workaround, this is a part of our code for aws_instance resource and seems to be doing its job

resource "aws_instance" "instance" {
  ...    
  private_ip                  = var.private_ip == "" ? null : var.private_ip
  ...

  dynamic "root_block_device" {
    for_each = var.root_block_device
    content {
      delete_on_termination = lookup(root_block_device.value, "delete_on_termination", null)
      encrypted             = lookup(root_block_device.value, "encrypted", null)
      iops                  = lookup(root_block_device.value, "iops", null)
      kms_key_id            = lookup(root_block_device.value, "kms_key_id", null)
      volume_size           = lookup(root_block_device.value, "volume_size", null)
      volume_type           = lookup(root_block_device.value, "volume_type", null)
    }
  }
  dynamic "ephemeral_block_device" {
    for_each = var.ephemeral_block_device
    content {
      device_name  = ephemeral_block_device.value.device_name
      no_device    = lookup(ephemeral_block_device.value, "no_device", null)
      virtual_name = lookup(ephemeral_block_device.value, "virtual_name", null)
    }
  }
}

I'm facing the same issues. And how do we address this with Terraform 0.11 as there is no null we could assign to the object.

This hack should help.

terraform {
    required_providers {
    aws = "~> 2.64.0"
  }
}

We have a module that takes an optional private_ip variable, and sets it blank as a default to have AWS automatically assign an IP when we don't wish to set one explicitly. Given sending a blank input here is valid for the AWS API, I think this validation is probably a _little_ over-zealous. (It's also a breaking change that possibly should have waited till a version 3 of the provider).

Thanks for that workaround of explicitly setting the version, @v3se .

Note that if you have explicitly defined an AWS provider you'll need to set that version within that block, not the top level terraform block, eg:

provider "aws" {
  region  = "us-east-1"
  version = "~> 2.64.0"
}

It appears to be some form of validation that's being done on the submitted value:
https://github.com/terraform-providers/terraform-provider-aws/pull/13033#discussion_r435955250

I was about to comment and say I just hit the same issue, and I am using private_ip in a similar fashion to everyone else, and since it seems logical to use it in such a fashion, the validation tests should be updated to also consider a blank/null value..

However, I see someone else has already submitted such a PR to address this issue: https://github.com/terraform-providers/terraform-provider-aws/pull/13640

Fix (allowing for private_ip = "") has been merged and will release with v2.66.0 of the Terraform AWS Provider, expected in next week's release. Apologies for the unintended interruptions in your environments!

Fix (allowing for private_ip = "") has been merged and will release with v2.66.0 of the Terraform AWS Provider, expected in next week's release. Apologies for the unintended interruptions in your environments!

Wouldn't such regression justify a dot release with just the regression fix? Say, 2.65.1?

Also experiencing this issue now on version 11

Fix (allowing for private_ip = "") has been merged and will release with v2.66.0 of the Terraform AWS Provider, expected in next week's release. Apologies for the unintended interruptions in your environments!

@anGie44 Will v2.66.0 be released this week?

yes, will be released later today @DanielZhangQD!

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 still getting this error with provider.aws v2.67.0

hi @luckyvalentine! thanks or commenting here. What does your config look like? Using the config provided in this issue's example and the same terraform version 11.14, I haven't been able to reproduce the error with v2.67.0 but I'd be happy to look into the behavior you're experiencing :)

Just ran into this when setting variable mount_target_ip_address default to "", to create resource:

resource "aws_efs_mount_target" "default" {
  count           = length(var.subnets) > 0 ? length(var.subnets) : 0
  file_system_id  = aws_efs_file_system.default.id
  ip_address      = var.mount_target_ip_address
  subnet_id       = var.subnets[count.index]
  security_groups = [aws_security_group.efs.id]
}

This is on aws = "~> 2.67.0".

Setting the default variable value to null fixes it:

variable "mount_target_ip_address" {
  type        = string
  description = "The address (within the address range of the specified subnet) at which the file system may be mounted via the mount target"
  default     = null
}

p.s. this is on v0.12.26

hi @elpy1, I believe what you're experiencing relates to the validation for IPv4 addresses added in https://github.com/terraform-providers/terraform-provider-aws/pull/13650. The fix https://github.com/terraform-providers/terraform-provider-aws/pull/13958 will be in v2.69.0 of the provider, expected to be released on Thursday.

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