hashicorp / terraform-provider-awscc

Terraform AWS Cloud Control provider
https://registry.terraform.io/providers/hashicorp/awscc/latest/docs
Mozilla Public License 2.0
263 stars 121 forks source link

awscc_rds_db_cluster does not support aurora-postgresql engine due to forced backtrack_window #1805

Open common-cranberry opened 5 months ago

common-cranberry commented 5 months ago

Community Note

Terraform CLI and Terraform AWS Cloud Control Provider Version

Affected Resource(s)

Terraform Configuration Files

Please include all Terraform configurations required to reproduce the bug. Bug reports without a functional reproduction may be closed without investigation.

resource "awscc_rds_db_cluster" "main" {
  # ...
  engine           = "aurora-postgresql"
}

resource "awscc_rds_db_cluster" "main" {
  # ...
  backtrack_window = 0
  engine           = "aurora-postgresql"
}

resource "awscc_rds_db_cluster" "main" {
  # ...
  backtrack_window = null
  engine           = "aurora-postgresql"
}

Debug Output

https://gist.github.com/common-cranberry/0e81762edaee4adce0c17c4c36fd54ad

Panic Output

Expected Behavior

The provider should not send any value for BacktrackWindow when engine is not implicitly or explicitly aurora-mysql which is the only engine to support this functionality.

Actual Behavior

The following response is tracked in CloudTrail no matter which of the above values for backtrack_window are provided, it is always set to 0 with this error message.

{
    "eventSource": "rds.amazonaws.com",
    "eventName": "CreateDBCluster",
    "awsRegion": "us-east-1",
    "sourceIPAddress": "cloudformation.amazonaws.com",
    "userAgent": "cloudformation.amazonaws.com",
    "errorCode": "InvalidParameterValueException",
    "errorMessage": "Backtrack is not enabled for the aurora-postgresql engine.",
    "requestParameters": {
      "backtrackWindow": 0,
    }
}

Steps to Reproduce

  1. terraform apply

Important Factoids

References

quixoticmonk commented 5 months ago

Thank you for opening the issue, @common-cranberry . The reason could be the default value set in the schema used by the provider. I have opened an internal ticket to review the schema and the applicability of the property.

quixoticmonk commented 4 months ago

@common-cranberry The change in the schema is available in the registry and is in 1.5.0. Can you retest ?