aws_elasticache_replication_group SnapshottingClusterId inference is incorrect in some cases

[piotrb]

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 other comments that do not add relevant new information or questions, 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.12.19

• provider.aws v2.39.0
• provider.random v2.2.0
• provider.template v2.1.2

Affected Resource(s)

aws_elasticache_replication_group

Terraform Configuration Files

# Copy-paste your Terraform configurations here - for large Terraform configs,
# please use a service like Dropbox and share a link to the ZIP file. For
# security, you can also encrypt the files using our GPG public key: https://keybase.io/hashicorp

Debug Output

See #1499

Panic Output

Expected Behavior

See #1499

Actual Behavior

See #1499

Steps to Reproduce

1. Create a non replicating single node redis cluster
2. in the AWS Console UI, click "Add Replication" on that cluster (this seems to be the only way I found for "upgrading" an existing cluster like this).
3. Add a replication group to TF and IMPORT a replication group with the same name of your original cluster
4. Add a replica to the group in TF by setting number_cache_clusters to 2
5. Try to enable snapshotting on this replication group

(same result as in #1499 happens)

Important Factoids

This is basically a re-open of #1499. I'm still experiencing a version of the original issue with the same error message.

It seems that the assumption in code as "fixed" in #14757 is just not correct in all cases.

It seems like when you upgrade an existing cluster for replication .. the naming conventions are different.

Perhaps the solution here is to not assume anything and just fetch the SnapshottingClusterId properly from the API. #1499 seems to say that this value is very much available in the API.

References

#1499

[piotrb]

Alternatively perhaps just expose the "Backup Node Id" field or something as a way of overriding the option in TF .. AWS makes you choose the node when you enable backups.

[piotrb]

It seems like a workaround for this is to enable backups on the aws console then TF seems to play along

[piotrb]

but still it seems like a weird assumption

[justinretzolk]

Hey @piotrb 👋 Thank you for taking the time to file this issue, and for the additional update. Given that there's been a number of AWS provider releases since the last update, can you confirm whether you're still experiencing this behavior?