Closed syphernl closed 2 years ago
/cc cc'ing in @nitrocode as he is the author of the changes done in v0.41.3.
I have created two PR's with slightly different directions:
Managed by Terraform
and not have their PG recreateddescription
or the family
changes.. With create_before_destroy
a new one should be created & associated before the old one will be removed.When I looked over the terraform resource in their code, I didn't see a ForceNew in the description so figured it was fine to add the descriptions. Good catch.
Couldn't we simply ignore changes if the description
is changed ?
lifecycle {
ignore_changes = [
description,
]
}
@nitrocode Oh wow, that actually sounds like a far easier solution 😄
The only downside is that the description
then can not be changed at all (which makes #143 not longer functional).
But I don't think anyone would actually need to do so since AWS requires a new PG to be created instead of being able to update it in-place.
If we go that route we can probably better close #143. PR #144 can be rewritten to go this route instead (or replaced, whichever is most practical).
I added the lifecycle ignore to 143 and the updated description is opt in if you set the description input to null.
I also set the last release as a pre-release
@syphernl thanks again for notifying us so quickly!
Describe the Bug
The changes done in v0.41.3 (#141) causes issues with existing resources. Since it re-uses the same name Terraform will try to remove it. But since it is in use, it will fail:
Expected Behavior
No errors when applying changes.
Potential solution
create_before_destroy
name_prefix
for a similar issue but unfortunately the aws_elasticache_parameter_group resource does not support this.If this is not possible we can work around this by making the description of the parameter group configurable, so that the
Managed by Terraform
value can be used for existing resources.