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 25, 2022. It is now read-only.
the issue can be summarized in one sentence: provider plugin implementation seems to remove qualified name prefix (such as /Compute-123456789/[email protected]/) from selected attributes in tfstate.
This causes unnecessary and, in this way, actually invalid rebuild (destroy & create) behavior, even though there is no change in .tf files in the meantime. This is particularly visible when using private images and/or IP networks created by different users.
In my opinion the reason is rather obvious and should be pretty straightforward to fix. The provider plugin implementation does not store fully qualified names in the tfstate file for the following attributes:
opc_compute_storage_volume.image_list
opc_compute_instance.networking_info.*.ip_network
opc_compute_instance.networking_info.*.vnic_sets
As a result it is risky to reference an existing IP network, VNIC Set or a private image created by other users, because it may result in unplanned and destructive reprovisioning.
Let's assume these are the resources created: /Compute-123456789/[email protected]/sandbox-ip-network and /Compute-123456789/[email protected]/sandbox-ip-network-vnics
Change opc_compute_instance.simplevm.networking_info.vnic_sets to /Compute-123456789/[email protected]/sandbox-ip-network-vnics
Change opc_compute_instance.simplevm.networking_info.ip_network to /Compute-123456789/[email protected]/sandbox-ip-network
Change opc_compute_storage_volume.simplevm_bootvolume.image_list to /Compute-123456789/[email protected]/OL76_UEKR5
User 3 : Provision compute-related resources as the third user (!) using simple-vm project (issue-1 branch)
User 3 : Run again terraform apply to see the invalid destructive plan
Expected Behavior
Plan: 0 to add, 0 to change, 0 to destroy.
Actual Behavior
-/+ opc_compute_storage_volume.simplevm_bootvolume (new resource required)
image_list: "OL76_UEKR5" => "/Compute-123456789/[email protected]/OL76_UEKR5" (forces new resource)
Plan: 1 to add, 0 to change, 1 to destroy.
Important Factoids
The source of the problem can be found in the state file:
The text was updated successfully, but these errors were encountered:
mtjakobczyk
changed the title
Terraform removes qualified name prefix from selected attributes in tfstate
Terraform is removing qualified name prefix from selected attributes in tfstate
Apr 16, 2019
Hey @mtjakobczyk, thanks for opening this issue. The sdk takes a simplified approach to dealing with ids for OCI-Classic resources by taking a single name and generating the full id for the resource. Unfortunately, because that functionality has been baked into the provider for so long, we can't just turn it off for certain attributes because that would end up breaking users that were depending on that functionality. We try to avoid breaking changes as best we can.
I believe I've found a decent solution however which is to check the full name being passed in and if the username or identity domain is different than we just return that full name so you won't see that diff anymore. That is in #167 and should be released shortly.
Hi there,
the issue can be summarized in one sentence: provider plugin implementation seems to remove qualified name prefix (such as
/Compute-123456789/[email protected]/
) from selected attributes in tfstate.This causes unnecessary and, in this way, actually invalid rebuild (destroy & create) behavior, even though there is no change in .tf files in the meantime. This is particularly visible when using private images and/or IP networks created by different users.
In my opinion the reason is rather obvious and should be pretty straightforward to fix. The provider plugin implementation does not store fully qualified names in the tfstate file for the following attributes:
opc_compute_storage_volume.image_list
opc_compute_instance.networking_info.*.ip_network
opc_compute_instance.networking_info.*.vnic_sets
As a result it is risky to reference an existing IP network, VNIC Set or a private image created by other users, because it may result in unplanned and destructive reprovisioning.
Terraform Version
Affected Resource(s)
Terraform Configuration Files
Steps to Reproduce
To experience the issue exactly as I did, you will need 3 users.
/Compute-123456789/[email protected]/OL76_UEKR5
/Compute-123456789/[email protected]/sandbox-ip-network
and/Compute-123456789/[email protected]/sandbox-ip-network-vnics
opc_compute_instance.simplevm.networking_info.vnic_sets
to/Compute-123456789/[email protected]/sandbox-ip-network-vnics
opc_compute_instance.simplevm.networking_info.ip_network
to/Compute-123456789/[email protected]/sandbox-ip-network
opc_compute_storage_volume.simplevm_bootvolume.image_list
to/Compute-123456789/[email protected]/OL76_UEKR5
terraform apply
to see the invalid destructive planExpected Behavior
Actual Behavior
Important Factoids
The source of the problem can be found in the state file:
The qualified name prefix (such as
/Compute-123456789/[email protected]/
) is removed (most probably onterraform refresh
).References
terraform apply
forces new resource #162The text was updated successfully, but these errors were encountered: