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

RDS instance: Terraform insisting on destroy-recreate RDS instances although their IDs are unchanged #9760

Closed
ghost opened this issue Aug 14, 2019 · 2 comments
Labels
service/rds Issues and PRs that pertain to the rds service. stale Old or inactive issues managed by automation, if no further action taken these will get closed. waiting-response Maintainers are waiting on response from community or contributor.

Comments

@ghost
Copy link

ghost commented Aug 14, 2019

This issue was originally opened by @dohoangkhiem as hashicorp/terraform#16724. It was migrated here as a result of the provider split. The original body of the issue is below.


We inspected our plan and realized Terraform keeps wanting to replace our RDS instances although their name, AZ have not changed, see below plan

-/+ module.magnolia.aws_db_instance.public_magnolia[0] (new resource required)
      id:                                "group1-site1-live-5-5-6-public1" => <computed> (forces new resource)
      address:                           "group1-site1-live-5-5-6-public1.czwmzj5tmahw.ap-southeast-1.rds.amazonaws.com" => <computed>
      allocated_storage:                 "5" => "5"
      apply_immediately:                 "" => <computed>
      arn:                               "arn:aws:rds:ap-southeast-1:218832052474:db:group1-site1-live-5-5-6-public1" => <computed>
      auto_minor_version_upgrade:        "true" => "true"
      availability_zone:                 "ap-southeast-1a" => <computed> (forces new resource)
      backup_retention_period:           "0" => <computed>
      backup_window:                     "20:55-21:25" => <computed>
      ca_cert_identifier:                "rds-ca-2015" => <computed>
      character_set_name:                "" => <computed>
      copy_tags_to_snapshot:             "true" => "true"
      db_subnet_group_name:              "khiem-db-subnet" => "khiem-db-subnet"
      endpoint:                          "group1-site1-live-5-5-6-public1.czwmzj5tmahw.ap-southeast-1.rds.amazonaws.com:5432" => <computed>
      engine:                            "postgres" => "postgres"
      engine_version:                    "9.5.4" => "9.5.4"
      hosted_zone_id:                    "Z2G0U3KFCY8NZ5" => <computed>
      identifier:                        "group1-site1-live-5-5-6-public1" => "group1-site1-live-5-5-6-public1"
      identifier_prefix:                 "" => <computed>
      instance_class:                    "db.t2.micro" => "db.t2.micro"
      kms_key_id:                        "" => <computed>
      license_model:                     "postgresql-license" => <computed>
      maintenance_window:                "fri:17:06-fri:17:36" => <computed>
      monitoring_interval:               "0" => "0"
      monitoring_role_arn:               "" => <computed>
      multi_az:                          "false" => "false"
      name:                              "magnolia" => "magnolia"
      option_group_name:                 "default:postgres-9-5" => <computed>
      parameter_group_name:              "default.postgres9.5" => "default.postgres9.5"
      password:                          <sensitive> => <sensitive> (attribute changed)
      port:                              "5432" => <computed>
      publicly_accessible:               "false" => "false"
      replicas.#:                        "0" => <computed>
      resource_id:                       "db-YHVKOYAXV7V3H33OEAH4SOKR6Q" => <computed>
      skip_final_snapshot:               "true" => "true"
      status:                            "available" => <computed>
      storage_type:                      "gp2" => "gp2"
      tags.%:                            "2" => "2"
      tags.Organization:                 "group1-site1" => "group1-site1"
      tags.Subscription:                 "group1-site1" => "group1-site1"
      timezone:                          "" => <computed>
      username:                          "postgres" => "postgres"
      vpc_security_group_ids.#:          "1" => "1"
      vpc_security_group_ids.1523498910: "sg-814006e7" => "sg-814006e7"

-/+ module.magnolia.aws_db_instance.public_magnolia[1] (new resource required)
      id:                                "group1-site1-live-5-5-6-public2" => <computed> (forces new resource)
      address:                           "group1-site1-live-5-5-6-public2.czwmzj5tmahw.ap-southeast-1.rds.amazonaws.com" => <computed>
      allocated_storage:                 "5" => "5"
      apply_immediately:                 "" => <computed>
      arn:                               "arn:aws:rds:ap-southeast-1:218832052474:db:group1-site1-live-5-5-6-public2" => <computed>
      auto_minor_version_upgrade:        "true" => "true"
      availability_zone:                 "ap-southeast-1a" => <computed> (forces new resource)
      backup_retention_period:           "0" => <computed>
      backup_window:                     "20:01-20:31" => <computed>
      ca_cert_identifier:                "rds-ca-2015" => <computed>
      character_set_name:                "" => <computed>
      copy_tags_to_snapshot:             "true" => "true"
      db_subnet_group_name:              "khiem-db-subnet" => "khiem-db-subnet"
      endpoint:                          "group1-site1-live-5-5-6-public2.czwmzj5tmahw.ap-southeast-1.rds.amazonaws.com:5432" => <computed>
      engine:                            "postgres" => "postgres"
      engine_version:                    "9.5.4" => "9.5.4"
      hosted_zone_id:                    "Z2G0U3KFCY8NZ5" => <computed>
      identifier:                        "group1-site1-live-5-5-6-public2" => "group1-site1-live-5-5-6-public2"
      identifier_prefix:                 "" => <computed>
      instance_class:                    "db.t2.micro" => "db.t2.micro"
      kms_key_id:                        "" => <computed>
      license_model:                     "postgresql-license" => <computed>
      maintenance_window:                "mon:18:18-mon:18:48" => <computed>
      monitoring_interval:               "0" => "0"
      monitoring_role_arn:               "" => <computed>
      multi_az:                          "false" => "false"
      name:                              "magnolia" => "magnolia"
      option_group_name:                 "default:postgres-9-5" => <computed>
      parameter_group_name:              "default.postgres9.5" => "default.postgres9.5"
      password:                          <sensitive> => <sensitive> (attribute changed)
      port:                              "5432" => <computed>
      publicly_accessible:               "false" => "false"
      replicas.#:                        "0" => <computed>
      resource_id:                       "db-AD5UTAPUZHDF44GPUTMR2FKOZQ" => <computed>
      skip_final_snapshot:               "true" => "true"
      status:                            "available" => <computed>
      storage_type:                      "gp2" => "gp2"
      tags.%:                            "2" => "2"
      tags.Organization:                 "group1-site1" => "group1-site1"
      tags.Subscription:                 "group1-site1" => "group1-site1"
      timezone:                          "" => <computed>
      username:                          "postgres" => "postgres"
      vpc_security_group_ids.#:          "1" => "1"
      vpc_security_group_ids.1523498910: "sg-814006e7" => "sg-814006e7"


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

The line
identifier: "group1-site1-live-5-5-6-public1" => "group1-site1-live-5-5-6-public1"

shows that no ID changes, and if we apply this it turns out that even availability zone does not change. But Terraform plan reports

id: "group1-site1-live-5-5-6-public1" => <computed> (forces new resource)
that makes me confused about the difference between id and identifier?

How/why this plan could happen? We have another RDS instance which is almost the same as above but it's not in a list (so, count = 1) and the plan does not touch that instance (which is correct behaviour). Is this a bug?

There's a note that these existing RDS instances were imported to the state manually like following

terraform import module.magnolia.aws_db_instance.public_magnolia[0] group1-site1-live-5-5-7-public1

terraform import module.magnolia.aws_db_instance.public_magnolia[1] group1-site1-live-5-5-7-public2

Terraform version is 0.10.7, we tried with 0.10.8 and 0.11 and it's still the same plan.

@nijave
Copy link
Contributor

nijave commented Oct 19, 2019

It looks like your databases want to land in a new AZ--maybe this is the real issue why they are showing they will be recreated and the id is showing up as a side effect. Without seeing the source Terraform it's hard to tell what's going on

availability_zone: "ap-southeast-1a" => <computed> (forces new resource)

@DrFaust92 DrFaust92 added the service/rds Issues and PRs that pertain to the rds service. label May 21, 2020
@justinretzolk justinretzolk added waiting-response Maintainers are waiting on response from community or contributor. and removed needs-triage Waiting for first response or review from a maintainer. labels Dec 9, 2021
Copy link

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 github-actions bot added the stale Old or inactive issues managed by automation, if no further action taken these will get closed. label Dec 25, 2024
@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Jan 26, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
service/rds Issues and PRs that pertain to the rds service. stale Old or inactive issues managed by automation, if no further action taken these will get closed. waiting-response Maintainers are waiting on response from community or contributor.
Projects
None yet
Development

No branches or pull requests

3 participants