aws_elasticache_subnet_group normalizes name to lowercase. #3120
+17
−4
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This addresses the broken refresh behavior discussed in #2178.
The Elasticache API accepts a mixed-case subnet group name on create, but normalizes it to lowercase before storing it. When retrieving a subnet group, the name is treated as case-sensitive, so the lowercase version must be used.
Given that the case within subnet group names is not significant, the new
StateFunc
on thename
attribute causes the state to reflect the lowercase version that the API uses, and changes in case alone will not show as a diff.Given that we must look up subnet group names as lowercase, we set the instance id to be a lowercase version of the user's provided name. This then allows a later
Refresh
call to succeed even if the user provided a mixed-case name in the config.Previously users could work around this by just avoiding putting uppercase letters in the name, but that is often inconvenient if e.g. the name is being constructed from variables defined elsewhere that may already have uppercase letters present.