Terraform-provider-aws: Changing aws_db_instance.backup_retention_period 0 -> 2 succeeds but change is not applied

[hashibot]

_This issue was originally opened by @Shugyousha as hashicorp/terraform#16221. It was migrated here as a result of the provider split. The original body of the issue is below._

---

When 'apply'ing the following state change

~ aws_db_instance.metabase_rds
backup_retention_period: "0" => "2"

for our RDS instance to change the backup_retention_period from 0 to two the apply succeeds but the state is not actually changed in AWS. Running 'plan' again still results in the same output. Running 'apply' a second time results in the same behaviour: the command succeeds but the actual value that can be checked in AWS does not change.

Terraform Version

Terraform v0.10.6

Terraform Configuration Files

resource "aws_db_instance" "metabase_rds" {
  count             = "${var.count_metabase_rds}"
  depends_on        = ["aws_security_group.metabase_rds"]
  identifier        = "${var.rds_postgre_metabase_identifier}"
  allocated_storage = "${var.rds_postgre_metabase_storage}"
  name              = "${var.rds_postgre_metabase_db_name}"
  engine            = "${var.rds_postgre_metabase_engine}"
  skip_final_snapshot    = true
  backup_retention_period = 2

  instance_class         = "${var.rds_postgre_metabase_instance_class}"
  username               = "${var.rds_postgre_metabase_master_username}"
  password               = "${var.rds_postgre_metabase_password}"
  vpc_security_group_ids = ["${aws_security_group.metabase_rds.id}"]
}

resource "aws_security_group" "metabase_rds" {
  count       = "${var.count_metabase_rds}"
  name        = "redacted${var.suffix}"
  description = "metabase_rds"

  # allow ssh
  ingress {
    from_port   = "22"
    to_port     = "22"
    protocol    = "tcp"
    cidr_blocks = "${var.ssh_cidr_blocks}"
  }

  # allow postgres port from metabase server
  ingress {
    from_port       = "5432"
    to_port         = "5432"
    protocol        = "tcp"
    security_groups = ["${aws_security_group.metabase.id}"]
  }

  # allow out
  egress {
    from_port   = "0"
    to_port     = "0"
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }

}
resource "aws_security_group" "metabase" {
  count       = "${var.count_metabase}"
  name        = "redacted${var.suffix}"
  description = "metabase"

  # allow ssh
  ingress {
    from_port   = "22"
    to_port     = "22"
    protocol    = "tcp"
    cidr_blocks = "${var.ssh_cidr_blocks}"
  }

  # allow web interface
  ingress {
    from_port   = "80"
    to_port     = "80"
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  # allow out
  egress {
    from_port   = "0"
    to_port     = "0"
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

Expected Behavior

aws_db_instance.backup_retention_period should have changed from 0 to 2 after successful 'apply'.

Actual Behavior

Running

terraform apply \
    -var-file=../production/terraform.tfvars \
    -state=../production/terraform.tfstate \
    .

succeeds but doesn't result in an actual change reflected in AWS.

Important Factoids

We are running terraform through make but that should not make a difference.

[bflad]

Check the instance to see if it has pending modifications. Without the apply immediately flag (matching the RDS API), many times any modify database instance commands will queue up until your next maintenance window (which if undefined is a random 30 minute block during the week).

[Shugyousha]

The "apply_immediately" flag was not set so I assume that was the issue.

After setting the "apply_immediately" flag to true, applying the change and then changing the retention period, the retention period value was changed immediately after applying again.

From what I can tell, this was just me not realizing that one has to set the "apply_immediately" flag.

[bflad]

Maybe it's worth adding some additional documentation to note this RDS behavior for (even seemingly benign) adjustments? I was caught up by this the first time I saw it too. ☺️

[github-actions[bot]]

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!

[hashibot[bot]]

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!