Currently, the terraform docs state that the volume name can be used to identify the volume for the fly_machine. While this is partially true (resource is created on fly.io), it leaves terraform in a broken state.
Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following
symbols:
~ update in-place
Terraform will perform the following actions:
# module.redis.fly_machine.app["syd"] will be updated in-place
~ resource "fly_machine" "app" {
~ cputype = "shared" -> (known after apply)
~ id = "*************" -> (known after apply)
~ mounts = [
~ {
~ encrypted = true -> (known after apply)
~ size_gb = 1 -> (known after apply)
~ volume = "vol_2yxp4mnk2z3r63qd" -> "org_app_dev_syd"
# (1 unchanged attribute hidden)
},
]
name = "org-app-dev-syd"
~ privateip = ""*************" -> (known after apply)
# (6 unchanged attributes hidden)
}
Plan: 0 to add, 1 to change, 0 to destroy.
Do you want to perform these actions?
Terraform will perform the actions described above.
Only 'yes' will be accepted to approve.
Enter a value: yes
Error: Provider produced inconsistent result after apply
│ When applying changes to module.redis.fly_machine.app["syd"], provider "provider[\"registry.terraform.io/fly-apps/fly\"]" produced an
│ unexpected new value: .mounts[0].volume: was cty.StringVal("org_app_dev_syd"), but now cty.StringVal("vol_2yxp4mnk2z3r63qd").
│
│ This is a bug in the provider, which should be reported in the provider's own issue tracker.
Currently, the terraform docs state that the volume
name
can be used to identify the volume for thefly_machine
. While this is partially true (resource is created on fly.io), it leaves terraform in a broken state.Steps to reproduce:
Define as follows:
Result
Workaround/resolution
terraform destroy
and thenterraform apply
Ideally the docs (and possibly the code) are updated to reflect that the
fly_volume
id
should be used instead ofname
for mounts.