Open philomory opened 2 months ago
Makes sense to me. I think all names should be overridable when it comes to upgrades and migrating existing resources to terraform modules
There are two parameter groups so each would need its own input
Have you considered putting in a pr?
Describe the Feature
We would like to be able to explicitly specify the names of the parameter groups created by this module
Expected Behavior
We need to be able to explicitly set the name of the parameter groups created by this module.
Use Case
We are performing a Blue/Green upgrade on our Aurora MySQL database, moving from MySQL 5.7-compatible Aurora to MySQL 8.x-compatible Aurora. To do so, we had to create a new 8.x-compatible parameter group to attach to the green cluster and instances. Since the two parameter groups need to exist concurrently, the new parameter group must have a different name than the original one.
Once we have completed the Blue/Green upgrade, however, if we use
terraform state rm
to remove the old parameter group from state, andterraform state import
to add the new one in its place, the module forces a replacement because the name is incorrect.Describe Ideal Solution
The ideal solution would be to be able to explicitly specify the name of the parameter group, overriding the module's calculated name.
Alternatives Considered
We basically have two alternatives:
Additional Context
No response