With aws_db_instance when you remove the snapshot_identifier it wants to force a new resource

[hashibot]

This issue was originally opened by @donnoman as hashicorp/terraform#11196. It was migrated here as part of the provider split. The original body of the issue is below.

---

Terraform Version

Terraform v0.8.4

Affected Resource(s)

• aws_db_instance

Terraform Configuration Files

  apply_immediately    = true
  allocated_storage    = 10
  engine               = "mariadb"
  engine_version       = "10.0.24"
  instance_class       = "db.t2.medium"
  # add this back in after RDS has been created
  name                 = "wordpress"
  identifier           = "lh-wordpress-${var.stage}"
  multi_az             = true
  username             = "${var.aws_rds_username}"
  password             = "${var.aws_rds_password}"
  db_subnet_group_name = "${var.aws_vpc_subnet_shared}"
  vpc_security_group_ids = ["${aws_security_group.rds.id}"]
  parameter_group_name = "default.mariadb10.0"
  final_snapshot_identifier = "lh-wordpress-${var.stage}-final"
  # remove the snapshot_identifier
  # snapshot_identifier = "lh-wordpress-staging-before-tf"
  copy_tags_to_snapshot = true
  backup_retention_period = 30
  backup_window = "07:00-08:00"
  maintenance_window = "sun:10:00-sun:11:00"
  tags {
    Name = "lh-wordpress-${var.stage}"
    cluster = "lh-wordpress-${var.stage}"
    terraform = "true"
  }
}

Debug Output

    snapshot_identifier:               "lh-wordpress-staging-before-tf" => "" (forces new resource)

Expected Behavior

No change required. In the future and for other environments I don't want this snapshot used. This snapshot was a restoration, because the last terraform run killed my DB

Actual Behavior

It wants to kill my newly restored db

Steps to Reproduce

Please list the steps required to reproduce the issue, for example:

1. terraform apply with the snapshot you need restored
2. remove the snapshot_identifier you no longer need because your db is now working
3. terraform apply

[mwarkentin]

Any thoughts on how this could be improved? We are having to do some pretty gnarly TF state manipulation when setting up plans to restore multiple db instances from snapshots.. would be nice to have a simple way of doing the one-off snapshot id.

[Tekila01]

same problem for me, what is the other way to fix that ?

[mafonso]

I'm working around this by having a lifecyle ignore_changes on the resource (within a module in my case)

  lifecycle {
    ignore_changes = ["snapshot_identifier"]
  }

and then I do something like
terraform taint -module=my_rds aws_db_instance.db
before restoring a snapshot.

Not ideal, but does the trick.
I would favor an approach where snapshot_identifier transitions to null were ignored.

"" -> "something" (triggers new resource)
"something" -> "something_else" (triggers new resource)
"something" -> "" (ignore, can be overridden with taint if necessary)

I'm thinking on the use case where I trigger an one-off restore by issuing

terraform apply [...] -var my_snapshot_identifier_var=my_snapshot_id

[kemra102]

This issue is still present today (we are using 0.10.8 still).

It's inconvenient keeping this ref around when the snapshot itself is long gone. This is analogous to the same procedure with EBS volumes. However with EBS volumes have been created from a snapshot you can safely remove the snapshot ref ID in Terraform without Terraform wanting to make any changes. If nothing else the behaviour is inconsistent.

[acdha]

I ran into this (and #2635) earlier and ended up using this process:

1. Create a snapshot and then create a copy using the KMS which will be used for storage encryption:

   $ aws rds create-db-snapshot --db-instance-identifier … --db-snapshot-identifier …
   $ aws rds copy-db-snapshot --source-db-snapshot-identifier … --target-db-snapshot-identifier … --kms-key-id …

2. Set kms_key_id to the ARN of the KMS key

3. Temporarily tell Terraform to create the database from the encrypted snapshot:

   snapshot_identifier = "…"

4. terraform apply

5. Remove the snapshot_identifier from the source file

6. terraform state pull to retrieve the state

7. Edit the state file to change snapshot_identifier to null and bump the serial value

8. terraform state push to upload the modified state file

[techdragon]

@acdha I think only 5, 6, 7, and 8 are specific to working around this issue, but I'm not really in a position to test it at the moment.

[ghost]

This has been released in version 3.32.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!

[ghost]

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!