Open hmmlopez opened 1 year ago
I am seeing something similar except it's when the contents of the file change. I'm having trouble reproducing it on a small scale, but in my case the local_file resource is buried a few modules deep.
I do notice when I run terraform apply
that a destruction event happens after the create event.
module.mod1.module.mod2.module.mod3.local_file.file: Creating...
[snip]
module.mod1.module.mod2.module.mod3.local_file.file: Creation complete after 0s [id=9daacaf1327023d49de76337a798ffe0ff8808f3]
[snip]
module.mod1.module.mod2.module.mod3.local_file.file (deposed object f537c4fb): Destroying... [id=6603365d67f2ce41538eefc330e6e6150ec6537d]
[snip]
module.mod1.module.mod2.module.mod3.local_file.file: Destruction complete after 0s
If I try terraform apply -target
module.mod1.module.mod2.module.mod3.local_file.file`, the ordering is correct.
If it matters, my filenames are directory/filename.ext
and there are multiple files being written to the same directory. I did try to -target 2 files in that directory, but that worked as expected as well.
I predict the deposed object f537c4fb
is the key and some form of object garbage collection is triggering the deletion phase instead of the normal plan methods.
I've tested with terraform 1.3.0, 1.3.1 and 1.3.2 as well as local module versions 2.2.2 and 2.2.3.
Early in my testing I did try create_before_destory = false
, but it was not used otherwise.
Looks like terraform does not manage file permissions. The file_permissions attribute is used when terraform creates the file, but it does not attempt to manage those permissions once the file exists. That is, if terraform creates the file with "0644" and you chmod 777 the file outside of terraform, terraform will not notice the change and fix the permissions on future runs of "terraform apply". Similarly, "terraform refresh" also does not update state with the actual file permissions.
terraform 1.5.7.
I don't think this problem is permissions-related. The problem is that this is not a reasonable situation to use create_before_destroy = true
.
The create_before_destroy
feature requires that the provider be able to support having both the new and old objects existing at the same time, but that isn't possible for local_file
because there can't be two files with the same filename at the same time.
Therefore I expect Terraform is effectively performing the following sequence of actions:
This is one of the hazards of using Terraform to manage files, since Terraform is really designed for managing objects via network APIs.
Avoiding the use of create_before_destroy
should instead cause the necessary ordering, where the old file gets deleted first and then the new one created in its place. The create_before_destroy
option is "sticky" in the Terraform state -- the old objects "remembers" that it was a create-before-destroy object -- so you may need to run two plan/apply rounds for the change to take effect.
Another option is to make sure each new version of the file has a different filename, in which case Terraform will be able to create the new one without overwriting the old one and can then delete the old one safely.
Terraform CLI and Provider Versions
Terraform v1.3.2 on linux_amd64
Terraform Configuration
Expected Behavior
Expected a file to be generated after running one time the command terraform apply when changing the file permission of an existing file. Seems it deletes the old file but a new file is not being created. After running terraform apply for second I see the new file is being created. No error is thrown after the first time running the apply method.
Actual Behavior
After 1 time terraform apply the file gets removed and no new file is created.
Steps to Reproduce
terraform apply
to create a new fileHow much impact is this issue causing?
Low
Logs
No response
Additional Information
Think this bug is only when using the lifecycle create_before_destroy.
Code of Conduct