random_password as auth_token rotation causes destroy and create because of transit_encryption handling != nuill

[Steve-Louie-Bose]

Found a bug? Maybe our Slack Community can help.

Describe the Bug

If one tries to set a new dynamic auth_token the way this module is written it will cause a destroy and create of the redis cache. The upstream aws provider added this support here.

The way transit_encryption_enabled is handled causes a destroy create when the auth_token is changed with a random_password as a source. Any dynamic input for auth_token causes this, a string literal will not replicate this issue. Because a string literal will be known at plan time. The work around with random_password has to be in state for us to get good modify only behavior.

Because the conditional var.transit_encryption_enabled || var.auth_token != null when auth_token is rotated but not yet known, terraform assumes the worst and I believe this causes the destroy create. (Credits to apparentlymart in the hangops slack. Thread here)

Expected Behavior

Using random_password to generate an auth_token and rotating it, I expected the redis cache to be modified not, destroy/created again. This is more disruptive than it has to be.

Steps to Reproduce

See this gist as a reference.

1. Apply random_password.password, aws_elasticache_replication_group.default and module.redis.
2. At the same time uncomment the code for random_password.password2 and use it in both redis blocks. (you'll see the resource works fine where the module destroy creates.)
   • the key to the above is in the same plan/apply phase we have to be adding a dynamic auth_token value which isn't fully known at plan time.
3. You'll see the redis cache get destroyed and recreated

---

The work around with the code as it is written is:

1. Apply random_password.password, aws_elasticache_replication_group.default and module.redis.
2. Plan and apply just random_password.password2 but do not reference it in the redis blocks.
3. Once password2 is known in state, use it as the auth_token in both redis blocks
4. this will only modify the cache instead of destroy create because the auth_token will be fully known since it's in the state.

Screenshots

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

Environment (please complete the following information):

OSX terraform 1.3.1 aws provider 4.63.0 random provider 3.5.1

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.

[gusse]

Anyone truly working on fixing this?