Cannot manage default aws_db_subnet_group

[tdmalone]

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)

• aws_db_subnet_group

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 ;)

[tdmalone]

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

lifecycle {
  ignore_changes = ["name"]
}

[ewbankkit]

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.

[ewbankkit]

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

[tdmalone]

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.

[TanmayaAPYL]

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

[ewbankkit]

As far as I remember, my approach for getting the working example in #4674 (comment) was to

• Remove the ValidateFunc from the name attribute https://github.com/terraform-providers/terraform-provider-aws/blob/471278e9e3fc09e742f1542a06ec67b822bef7ab/aws/resource_aws_db_subnet_group.go#L33-L39
• Add a CustomizeDiff function that validated the DB subnet group name only when the resource was being created:

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

[maiconcarraro]

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"
  ...
}

[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!

[github-actions]

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.