aws_rds_cluster_parameter_group plan shows changes after applying

[benberg86]

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

Affected Resource(s)

aws_rds_cluster_parameter_group

Terraform Configuration Files

resource "aws_rds_cluster_parameter_group" "cluster_parameters" {
  name   = "${var.serviceName}-aurora-param-group"
  family = "aurora-mysql5.7"

    parameter {
      name  = "default_password_lifetime"
      value = "0"
    }

  parameter {
    name  = "innodb_purge_threads"
    value = "1"
  }
  parameter {
    name  = "lower_case_table_names"
    value = "1"
  }
}

Expected Behavior

Once applying the cluster parameters, subsequent plan and apply should not make changes to the db cluster parameter group.

Actual Behavior

On each plan or apply, cluster parameter group is attempting to modify the resource and does not make and changes.

Steps to Reproduce

1. terraform apply -> yes
2. terraform apply -> see changes

Important Factoids

In this example, commenting out the parameter below resolves the unintended behavior.

parameter {
name = "default_password_lifetime"
value = "0"
}

References

Believe this may be similar to #593 that occurs when attempting to set a parameter to the default value, except on the cluster parameter group resource.

[smetj]

It seems this is still an issue on

Terraform v0.11.13
+ provider.aws v2.4.0
+ provider.template v2.1.0

... anyone following up on this?

[jbscare]

We've encountered an issue like this when removing a parameter from our configuration that we'd previously set. For example, we used to set server_audit_excl_users in a parameter group to a list of users, and now we want to remove those users and not set it any more. If we do this, it works, and terraform plan shows no changes after applying:

  parameter {
    name = "server_audit_excl_users"
    value = ""
  }

If we then remove it from the config, though, terraform plan says:

  ~ aws_rds_cluster_parameter_group.aurora-czen-cluster
      parameter.#:                       "16" => "15"

and a list of all the parameters. grep-ing out things that are the same before and after (terraform plan | sed -e '/"\(.*\)" => "\1"/d') shows this:

Terraform will perform the following actions:

  ~ aws_rds_cluster_parameter_group.aurora-czen-cluster
      parameter.#:                       "16" => "15"
      parameter.3481764409.apply_method: "immediate" => ""
      parameter.3481764409.name:         "server_audit_excl_users" => ""


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

Applying that plan says

Apply complete! Resources: 0 added, 1 changed, 0 destroyed.

but a subsequent terraform plan shows the same pending change.

This is with these:

+$ terraform provider -version
Terraform v0.11.14
+ provider.aws v2.20.0

[jbscare]

Hm, some more data: I tried removing and importing the parameter group, and it had no effect; but I did this:

aws rds reset-db-cluster-parameter-group --db-cluster-parameter-group-name prod-aurora-czen-cluster --parameters ParameterName=server_audit_excl_users,ApplyMethod=immediate

And then my terraform plan said no changes. Hm.

[kpocius]

Thanks for a workaround, @jbscare! In my case it was a single RDS instance, so I used:

aws rds reset-db-parameter-group --db-parameter-group-name <NAME> --reset-all-parameters

[domcleal]

Believe this may be similar to #593 that occurs when attempting to set a parameter to the default value, except on the cluster parameter group resource.

Looks like it, yeah. The fix for that was in #3182 but was only applied to the non-cluster parameter group resource.

As a workaround I used the dynamic block in 0.12 to skip setting a parameter when null - but you could equally compare against the default value by changing the for_each line:

  dynamic "parameter" {
    # Allow read_only to be `null`, so this param is removed and so defaults to {TrueIfReplica}
    #
    # Works around https://github.com/terraform-providers/terraform-provider-aws/issues/5410
    # where setting a parameter to a default value will continuously try to set it as it isn't
    # recognised as set by the user
    for_each = var.read_only != null ? [true] : []
    content {
      name  = "read_only"
      value = var.read_only
    }
  }

If the var is null/default then the dynamic block means the parameter's not set. The provider then seems to correctly remove the parameter if it had been set and is now null.

[olenm]

rds reset-db-cluster-parameter-group --db-cluster-parameter-group-name prod-aurora-czen-cluster --parameters ParameterName=server_audit_excl_users,ApplyMethod=immediate

sadly this did not work for me - at least with parameter-name log_output - I'm wondering if #3182's logic isnt copy-able into cluster-parameter-group's logic to fix it up.

Edit: comparing the cluster-param-group and param-group source files, yes it really does look like the code changes from 3182 can be easily copied/referenced directly into updating cluster-param-group. only external call new that would need updating via copy-paste is DescribeDBClusterParametersPages