Terraform v0.11.14 and Terraform AWS provider 2.65.0
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}"
}
should ignore when no IPv4 is provided
Error: module.x.aws_instance.ec2_node: expected private_ip to contain a valid IPv4 address, got:
terraform plan
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 withv2.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 withv2.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!
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: