aws_elasticache_parameter_group should have create_before_destroy set to true

[sherifkayad]

Found a bug? Maybe our Slack Community can help.

Describe the Bug

While attempting to upgrade to Redis version 6.2 on AWS, I tried renaming the family and I got an error as follows:

Error: error deleting ElastiCache Parameter Group (my-redis): InvalidCacheParameterGroupState: One or more cache clusters are still members of this parameter group my-redis, so the group cannot be deleted.
│       status code: 400, request id: 84aa3858-e72d-47ca-92c3-3b33e7093a87

Expected Behavior

The upgrade should go through and the new parameter group should be created first

Steps to Reproduce

Steps to reproduce the behavior:

1. Go to '...'
2. Run '....'
3. Enter '....'
4. See error

Screenshots

If applicable, add screenshots or logs to help explain your problem.

Environment (please complete the following information):

Anything that will help us triage the bug will help. Here are some ideas:

• OS: [e.g. Linux, OSX, WSL, etc]
• Version [e.g. 10.15]

Additional Context

Add any other context about the problem here.

[joshuabaird]

As is, this bug prevents using this module for major version upgrades.

[grietine]

Any thoughts when this will be fixed?

[evanstachowiak]

It's actually a bit more complicated than just setting create_before_destroy. The parameter group name doesn't have the version name, so it will fail if create_before_destroy is set because it cannot create a new group with the same name.

[ragumix]

Maybe it can be fixed by adding depends_on block?

[alexandrud]

I believe the fix would be to add some random suffix so it creates a new param group name. This would force the creation of a new param group, move the cluster to the new param group and remove the old one. Like @joshuabaird said, this prevents major version upgrades as the family variable forces the param group to be recreated.

[joshuabaird]

I have a PR open to fix this, but it has a bug and I haven't had the time to fix it yet. Will try to look at it soon.

#189

[Legeril]

@joshuabaird @sherifkayad @evanstachowiak I fixed this in my own instance of the cloudposse code by making the replication group depend_on the param group. That way the create order is param group then replication group, and a destroy etc is the inverse