Open lawa1974 opened 11 months ago
Thank you for reporting the issue. We have raised an internal ticket to track this. Our service engineers will get back to you.
@lawa1974 Are you trying to specify system-tags in your Terraform config for the instance? Please post a snippet of your config file to help me better understand what is happening.
No, I don't want to do anything with system tags. I created an instance, and if, for example, I call 'terraform apply' next time without any change in terraform code, Terraform wants to change the system tags (see the snippet above).
I would expect the following output: Plan: 0 to add, 0 to change, 0 to destroy.
But, we get this output: Plan: 0 to add, 1 to change, 0 to destroy.
I'm still trying to reproduce this and could use some more information:
Hi,
1) In the tfstate file there's an entry "system_tags": null
for the instance
2) The PCA console shows only defined_tags but no system tags
3) Yes, I see the same behaviour that I have reported which means that terraform tries to change the system tags.
@lawa1974 I'm not having any luck reproducing this issue. If you could share your Terraform configuration for this instance that would be helpful.
Hi @nolancaster. Thank you for looking at this issue. My team are facing a similar issue.
Just to confirm you are trying to reproduce this issue on a Private Cloud Appliance (PCA) engineered system version 3, or on OCI?.
Much like @lawa1974 we are not updating system_tags
but the terraform provider is reporting the system_tags
in the plan as "known after apply"
.
We have tried including system_tags in a lifecycle
block under a ignore_changes
list but this failed to resolve the issue.
My vm creation looks similar to this:
resource "oci_core_instance" "vms_to_deploy" {
for_each = local.vms_to_deploy
availability_domain = var.availability_domain
compartment_id = var.compartment_id
shape = local.shape
display_name = each.value.display_name
metadata = each.value.ssh_key
source_details {
source_type = "image"
source_id = each.value.image_id
}
shape_config {
ocpus = 4
memory_in_gbs = 16
}
create_vnic_details {
subnet_id = var.subnet_id
nsg_ids = [var.nsg_id]
assign_public_ip = "false"
display_name = format("%s_vnci", each.value.display_name)
availability_config {
is_live_migration_preferred = true
recovery_action = "RESTORE_INSTANCE"
}
}
}
A satisfactory solution might be found with this https://github.com/hashicorp/terraform/issues/23814 but it involves modifying the provider so that the Computed:
field in the resources schemas is set to false.
same issue here with PCA 3.0.2. every tf plan wants to update extended_metadata and system_tags (known after apply) for each oci_core_instance, even though NOTHING has changed.
Expected behavior for 17 VMs deployed on PCA: Plan: 0 to add, 0 to change, 0 to destroy.
Current behavior: Plan: 0 to add, 17 to change, 0 to destroy.
Is there any update on this bug? I know that the PCA is a much smaller use case than OCI; however, this makes it very difficult to identify actual changes in a large environment. We effectively can't use any automation that works on "detailed-exitcode," as this obscured by the high volume of (non-existent) changes. This is effectively the same issue as Issue 1923 with the same, painful result.
The root of this issue appears to be a difference in the API responses from a Private Cloud Appliance (PCA) versus OCI. Responses for the GetInstance operation do not provide a system_tags
field when called against the PCA. This results in the terraform provider storing the system_tags
attribute with a null
value in the state file.
This differs from the behaviour of the defined_tags
attribute. Even when this field is left unspecified for the oci_core_instance resource the PCA API returns an empty map {}
as the result. This means terraform stores the defined_tags
attribute as {}
in the state file. Consequently, we do not see terraform plan constantly reporting a (known after apply) change for this field even if its value is not specified in the configuration.
In the case of a local state file manually editing an oci_core_instance resources system_tags = null
so that it is replaced with system_tags = {}
within the state file itself will remove the change behaviour in the terraform plan. Similar behaviour is exhibited for extended_metadata
and metadata
fields. However, this is not a satisfactory solution.
The reported changes from the terraform plan can be removed by altering how the provider stores the fields system_tags
, extended_metadata
, and metadata
in the case of receiving an API response either missing these attributes or specifying them as null
. In such cases the provider simply has to record the values of these attributes as being the empty map {}
. A code change like this one https://github.com/cam-mclaren/terraform-provider-oci/commit/019c4d21d417d4c5bac925844aa11842d2f3da18 can resolve the issue.
PR For this issue has been raised https://github.com/oracle/terraform-provider-oci/pull/2137
FWIW, this issue still exists in 5.45.0.
Community Note
Terraform Version and Provider Version
Terraform v1.3.6 on linux_amd64
Affected Resource(s)
affected_resources = oci_core_instance
Terraform Configuration Files
Debug Output
Panic Output
Expected Behavior
Actual Behavior
Every terraform run results in a modification. Adding system_tags to lifecycle { ignore_changes = [system_tags] } doesn't help. Still triggers the modification request though.
Steps to Reproduce
Run terraform apply once to create the instance Run terraform apply again - this should not result in any modification.
Important Factoids
We run terraform /OCI provider against a Oracle Private Cloud Appliance (PCA).
References