Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"enable_dns_hostnames = false" on aws_default_vpc resource doesn't work #14911

Closed
wes-novack opened this issue Aug 29, 2020 · 7 comments · Fixed by #22776
Closed

"enable_dns_hostnames = false" on aws_default_vpc resource doesn't work #14911

wes-novack opened this issue Aug 29, 2020 · 7 comments · Fixed by #22776
Labels
bug Addresses a defect in current functionality. service/ec2 Issues and PRs that pertain to the ec2 service.
Milestone

Comments

@wes-novack
Copy link

wes-novack commented Aug 29, 2020

When setting enable_dns_hostnames = false on aws_default_vpc resource, the Terraform applies successfully with no warnings and no errors, but the setting does not actually get turned off on the target resource.

Example code:

resource "aws_default_vpc" "default" {
  enable_dns_hostnames = false
  enable_dns_support = false
  tags = {
    Name = "Default VPC"
  }
}

provider "aws" {
  region = "us-west-2"
}

Example Terraform output:

$ terraform init

Initializing the backend...

Initializing provider plugins...
- Checking for available provider plugins...
- Downloading plugin for provider "aws" (hashicorp/aws) 3.4.0...

The following providers do not have any version constraints in configuration,
so the latest version was installed.

To prevent automatic upgrades to new major versions that may contain breaking
changes, it is recommended to add version = "..." constraints to the
corresponding provider blocks in configuration, with the constraint strings
suggested below.

* provider.aws: version = "~> 3.4"

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.

$ terraform apply

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # aws_default_vpc.default will be created
  + resource "aws_default_vpc" "default" {
      + arn                              = (known after apply)
      + assign_generated_ipv6_cidr_block = (known after apply)
      + cidr_block                       = (known after apply)
      + default_network_acl_id           = (known after apply)
      + default_route_table_id           = (known after apply)
      + default_security_group_id        = (known after apply)
      + dhcp_options_id                  = (known after apply)
      + enable_classiclink               = (known after apply)
      + enable_classiclink_dns_support   = (known after apply)
      + enable_dns_hostnames             = false
      + enable_dns_support               = false
      + id                               = (known after apply)
      + instance_tenancy                 = (known after apply)
      + ipv6_association_id              = (known after apply)
      + ipv6_cidr_block                  = (known after apply)
      + main_route_table_id              = (known after apply)
      + owner_id                         = (known after apply)
      + tags                             = {
          + "Name" = "Default VPC"
        }
    }

Plan: 1 to add, 0 to change, 0 to destroy.

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

aws_default_vpc.default: Creating...
aws_default_vpc.default: Creation complete after 3s [id=<redacted_vpc_id>]

Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

Specifically, notice that the plan shows the desired setting:
+ enable_dns_hostnames = false

However, after the run, this setting is still enabled on the VPC, and if I look at the Terraform state, it shows as true in the state file.

$ terraform state show aws_default_vpc.default
# aws_default_vpc.default:
resource "aws_default_vpc" "default" {
    arn                              = "arn:aws:ec2:us-west-2:<redacted_owner_id>:vpc/<redacted_vpc_id>"
    assign_generated_ipv6_cidr_block = false
    cidr_block                       = "172.31.0.0/16"
    default_network_acl_id           = "acl-0e1e5b307afb33205"
    default_route_table_id           = "rtb-0d0a36bb1636188a6"
    default_security_group_id        = "sg-00ec22fb138b3bd8e"
    dhcp_options_id                  = "dopt-2b204453"
    enable_classiclink               = false
    enable_classiclink_dns_support   = false
    enable_dns_hostnames             = true
    enable_dns_support               = false
    id                               = "<redacted_vpc_id>"
    instance_tenancy                 = "default"
    main_route_table_id              = "rtb-0d0a36bb1636188a6"
    owner_id                         = "<redacted_owner_id>"
    tags                             = {
        "Name" = "Default VPC"
    }
}
@ghost ghost added the service/ec2 Issues and PRs that pertain to the ec2 service. label Aug 29, 2020
@github-actions github-actions bot added the needs-triage Waiting for first response or review from a maintainer. label Aug 29, 2020
@wes-novack
Copy link
Author

Oddly, if you run a second apply, then it detects it as an update in-place
~ enable_dns_hostnames = true -> false

And then the second apply seems to successfully update the setting on the VPC

Regardless, this still looks like a bug and should be addressed so that the setting gets implemented on the first apply, as defined in the terraform and shown in the plan.

@ewbankkit ewbankkit added bug Addresses a defect in current functionality. and removed needs-triage Waiting for first response or review from a maintainer. labels Aug 30, 2020
@Rajendraladkat1919
Copy link

I am running it with "enable_dns_hostnames = true" but still it fails during destroy. I tried to destroy multiple times.
Terraform version: Terraform v0.13.1
aws_provider: version = "~> 3.0"

Apply complete! Resources: 1 added, 0 changed, 0 destroyed.
$ terraform destroy
aws_vpc.test: Refreshing state... [id=vpc-0c88d416b6f406a62]
Do you really want to destroy all resources?
  Terraform will destroy all your managed infrastructure, as shown above.
  There is no undo. Only 'yes' will be accepted to confirm.

  Enter a value: yes


Destroy complete! Resources: 0 destroyed.
$ terraform destroy
Do you really want to destroy all resources?
  Terraform will destroy all your managed infrastructure, as shown above.
  There is no undo. Only 'yes' will be accepted to confirm.

  Enter a value: yes


Destroy complete! Resources: 0 destroyed.

### main.tf
`resource "aws_vpc" "test" {
 cidr_block = "10.200.0.0/16"
 instance_tenancy = "default"
 enable_dns_hostnames             = true
 enable_dns_support               = true

 tags = {
     Name = "main"
 }
}`

@ewbankkit
Copy link
Contributor

The cause is the fact that the default value for enable_dns_hostnames is false and the non-standard way that the default VPC resource adopts the existing AWS resource rather than creating it.

@Rajendraladkat1919
Copy link

@ewbankkit you mean this is the bug from AWS vpc resource. What will be the terraform provide it will only take its default value is 'false' only.

@anGie44
Copy link
Contributor

anGie44 commented Jan 26, 2022

Fixed with #22253

@github-actions
Copy link

This functionality has been released in v4.0.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. Thank you!

@github-actions
Copy link

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 have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators May 14, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Addresses a defect in current functionality. service/ec2 Issues and PRs that pertain to the ec2 service.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants