Terraform-provider-aws: Cannot manage default aws_db_subnet_group

Created on 29 May 2018  Ā·  7Comments  Ā·  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 "me too" comments, 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.7
+ provider.aws v1.20.0

Affected Resource(s)

Terraform Configuration Files

First example:

resource "aws_db_subnet_group" "default" {
  name = "default"
  ...
}

Second example:

resource "aws_db_subnet_group" "default" {
  name = "main"
  ...
}

Expected Behavior

With the first example, I expected that Terraform would either generate a diff between my config and the live resource, or advise that everything is up-to-date.

With the second example, I _would_ expect the resource needs recreation, which is exactly what happens - I include this just to demonstrate that given that 'default' isn't accepted, it's not possible to directly manage this resource after importing it.

Actual Behavior

$ terraform import aws_db_subnet_group.default default

aws_db_subnet_group.default: Importing from ID "default"...
aws_db_subnet_group.default: Import complete!
  Imported aws_db_subnet_group (ID: default)
aws_db_subnet_group.default: Refreshing state... (ID: default)

Import successful!

The resources that were imported are shown above. These resources are now in
your Terraform state and will henceforth be managed by Terraform.

With first example config from above:

$ terraform apply

Error: aws_db_subnet_group.default: "Default" is not allowed as "name"

With second example config from above:

$ terraform apply

...
-/+ aws_db_subnet_group.default (new resource required)
      id:                                "default" => <computed> (forces new resource)
      arn:                               "arn:aws:rds:ap-southeast-2:xxxxxxxxxxxx:subgrp:default" => <computed>
      description:                       "default" => "Managed by Terraform"
      name:                              "default" => "main" (forces new resource)
      name_prefix:                       "" => <computed>
...

Steps to Reproduce

  1. terraform import aws_db_subnet_group.default default
  2. Use the first example config above - i.e. setting the name of the imported db_subnet_group to 'defualt'
  3. Observe that the name 'default' is not allowed
  4. Observe that it's now not possible to directly manage this resource via Terraform ;)
new-resource servicrds

Most helpful comment

I'm currently working around this by setting the name to anything other than 'default' and including:

lifecycle {
  ignore_changes = ["name"]
}

All 7 comments

I'm currently working around this by setting the name to anything other than 'default' and including:

lifecycle {
  ignore_changes = ["name"]
}

The problem is that validateDbSubnetGroupName is being called in all scenarios and not just when a new DB Subnet Group is being created.
If we change that then you should be able to import

$ terraform import aws_db_subnet_group.default default
aws_db_subnet_group.default: Importing from ID "default"...
aws_db_subnet_group.default: Import complete!
  Imported aws_db_subnet_group (ID: default)
aws_db_subnet_group.default: Refreshing state... (ID: default)

Import successful!

The resources that were imported are shown above. These resources are now in
your Terraform state and will henceforth be managed by Terraform.

write some Terraform code

resource "aws_db_subnet_group" "default" {
 name = "default"
 description = "default"

 subnet_ids = [
   ...
 ]
}

and then

$ terraform plan
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but will not be
persisted to local or remote state storage.

aws_db_subnet_group.default: Refreshing state... (ID: default)

------------------------------------------------------------------------

No changes. Infrastructure is up-to-date.

This means that Terraform did not detect any differences between your
configuration and real physical resources that exist. As a result, no
actions need to be performed.

I think we'll find the same issue with importing the default

  • aws_redshift_subnet_group
  • aws_neptune_subnet_group
  • aws_dms_replication_subnet_group
  • aws_dax_subnet_group

Given that this is tagged as ā€˜new resource’, I’m guessing it’ll go the way of a resource such as ā€œaws_default_db_subnet_groupā€, similar to eg. aws_default_vpc - given these default resources do behave slightly differently to their ā€˜normal’ counterparts.

Perhaps we might need ā€˜default’ subnet resources for redshift, neptune and dms as well then.

Do we know if there is any progress on the topic?

As far as I remember, my approach for getting the working example in https://github.com/terraform-providers/terraform-provider-aws/issues/4674#issuecomment-410391001 was to

func resourceAwsDbSubnetGroupCustomizeDiff(diff *schema.ResourceDiff, meta interface{}) error {
    if diff.Id() == "" {
        // New resource.
                name:= diff.Get("name").(string);
        // Same logic as validateDbSubnetGroupName.
        }
}

I'm using Terraform v0.12.26 and for me worked just removing name line.

resource "aws_db_subnet_group" "default" {
  name = "default"
  description = "default"
  ...
}

to

resource "aws_db_subnet_group" "default" {
  description = "default"
  ...
}
Was this page helpful?
0 / 5 - 0 ratings