Set delete-before-replace for manually-named resources. #465
Conversation
Determine if a resource is auto-named by checking its list of top-level defaults for a property that was populated by a default value that is an autoname. If the defaults list is missing, consider the resource auto-named for better backwards compatibility. These changes also fix a bug in the logic that determined the legacy replaces list. Fixes #383.
As of this writing, that will not work. We will need to change the CLI in order to provide that override. |
With these changes, a user may explicitly set `deleteBeforeReplace` to `false` in order to disable DBR behavior for a particular resource. This is the SDK + CLI escape hatch for cases where the changes in pulumi/pulumi-terraform#465 cause undesirable behavior.
With these changes, a user may explicitly set `deleteBeforeReplace` to `false` in order to disable DBR behavior for a particular resource. This is the SDK + CLI escape hatch for cases where the changes in pulumi/pulumi-terraform#465 cause undesirable behavior.
With these changes, a user may explicitly set `deleteBeforeReplace` to `false` in order to disable DBR behavior for a particular resource. This is the SDK + CLI escape hatch for cases where the changes in pulumi/pulumi-terraform#465 cause undesirable behavior.
|
One thing I should point out: this will enable DBR for any resource that is not autonamed, which is subtly different than enabling DBR only for resources that are manually-named. With these changes, any resource that does not have an autonameable property will always be DBR'd. There are 276 such resources in the AWS provider at the moment; I haven't looked at the others. |
The original code would have enabled DBR for any resource that is not autonamed, which is subtly different than enabling DBR only for resources that are manually-named. With those changes, any resource that does not have an autonameable property would always have been deleted before being replaced. This is probably not the correct default for resources that do not have an autonamable property. This commit changes the way we decide whether or not a resource's name requires DBR: rather than looking for the presence of a default that came from an autoname, the code now looks for an input property with a manually-specified (i.e. non-default) value that _could_ have been autonamed.
|
I have added a commit that changes the way we decide whether or not a resource's name requires DBR: rather than looking for the presence of a default that came from an autoname, the code now looks for an input property with a manually-specified (i.e. non-default) value that could have been autonamed. |
|
I have manually validated that this works as expected with resources that are not auto-nameable (e.g. EC2 instances) as well as with resources that are. I have also validated that |
Determine if a resource is auto-named by checking its list of top-level
defaults for a property that was populated by a default value that is an
autoname. If the defaults list is missing, consider the resource
auto-named for better backwards compatibility.
These changes also fix a bug in the logic that determined the legacy
replaces list.
Fixes #383.