You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Mar 1, 2024. It is now read-only.
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.
Ideally the docs (and possibly the code) are updated to reflect that the fly_volumeid should be used instead of name for mounts.
The text was updated successfully, but these errors were encountered:
oscarhermoso
changed the title
fly_machine.mounts.volume Volume should not accept name or IDfly_machine.mounts.volume Volume should not accept name
Apr 29, 2023
oscarhermoso
changed the title
fly_machine.mounts.volume Volume should not accept namefly_machine.mounts.volume should only accept fly_voume.id, not fly_voume.nameApr 29, 2023
oscarhermoso
changed the title
fly_machine.mounts.volume should only accept fly_voume.id, not fly_voume.namefly_machine.mounts.volume should only accept fly_volume.id, not fly_volume.nameApr 29, 2023
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
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.
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.The text was updated successfully, but these errors were encountered: