aws_rds_cluster_parameter_group values not saving and are re-set on every apply

[elias314]

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.22.0

Affected Resource(s)

• aws_rds_cluster_parameter_group

Terraform Configuration Files

resource "aws_rds_cluster_parameter_group" "Aurora_cluster_parameter_group" {
  name        = "custom-aurora-parameter-group"
  description = "Custom DBClusterParameterGroup for aurora-postgresql9.6"
  family      = "aurora-postgresql9.6"

  parameter {
    name         = "client_encoding"
    value        = "utf8"
    apply_method = "immediate"
  }

  parameter {
    name         = "rds.force_ssl"
    value        = "1"
    apply_method = "pending-reboot"
  }

  parameter {
    name         = "ssl"
    value        = "1"
    apply_method = "pending-reboot"
  }
}

Debug Output

Panic Output

Expected Behavior

After applying the parameter group once, future applies should so show no changes.

Actual Behavior

Terraform always reapplies the settings even if they're already set correctly. Note that the paramters do get set correctly in AWS, but TF thinks they haven't so it applies them again.

Terraform will perform the following actions:

  ~ aws_rds_cluster_parameter_group.Aurora_cluster_parameter_group
      parameter.#:                       "2" => "3"
      parameter.1088520732.apply_method: "" => ""
      parameter.1088520732.name:         "" => "ssl"
      parameter.1088520732.value:        "" => "1"
      parameter.1124637299.apply_method: "immediate" => ""
      parameter.1124637299.name:         "client_encoding" => "client_encoding"
      parameter.1124637299.value:        "utf8" => "utf8"
      parameter.2349693848.apply_method: "pending-reboot" => ""
      parameter.2349693848.name:         "rds.force_ssl" => "rds.force_ssl"
      parameter.2349693848.value:        "1" => "1"


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

Steps to Reproduce

1. Run terraform apply on the above sample.
2. Run terraform apply again with no changes.

Important Factoids

References

[saravanan30erd]

@bflad When reading the cluster parameters we are using value user in Source argument to filter user customized parameters, looks like it will return only non-default parameters.

// Only include user customized parameters as there's hundreds of system/default ones
describeParametersOpts := rds.DescribeDBClusterParametersInput{
DBClusterParameterGroupName: aws.String(d.Id()),
Source: aws.String("user"),
}

In above example, 1 is the default value for ssl. so it ll not return this parameter and resulted in not storing the ssl in state. What we will do in this case? Can we set the parameters in create(only) instead of read ?

[bflad]

We might need to setup some logic for ignoring default parameters and their values so they do not show up as a difference during plan, similar to how we do for Cognito schema attributes. We should always perform the d.Set() during read to detect drift: https://www.terraform.io/docs/extend/best-practices/detecting-drift.html

[jc-asdf]

Ran into this last week and whipped together a PR (above) using the same approach as was used in hashicorp/terraform#8603; including a new test.

[bflad]

The fix for apply_method showing updates has been merged and will release with version 1.42.0 of the AWS provider, likely today or tomorrow. As for suppressing the difference for user supplied parameters that match "standard" parameters, let's consolidate discussions and efforts in #5410 👍

[bflad]

This has been released in version 1.42.0 of the AWS provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading.

[smetj]

I have exactly this issue with aws provider 2.53 ... anyone else experiencing that?

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