system_tags on oci_core_instance triggers a modification request every time

[lawa1974]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Terraform Version and Provider Version

Terraform v1.3.6
on linux_amd64

• provider registry.terraform.io/hashicorp/oci v5.4.0

Affected Resource(s)

affected_resources = oci_core_instance

Terraform Configuration Files

...

Debug Output

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.compute_instance_simple.oci_core_instance.compute_instance_simple[0] will be updated in-place
  ~ resource "oci_core_instance" "compute_instance_simple" {
        id                  = "ocid1.instance...................2wd"
      + system_tags         = (known after apply)
        # (17 unchanged attributes hidden)

        # (4 unchanged blocks hidden)
    }

Plan: 0 to add, 1 to change, 0 to destroy.

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

[tf-oci-pub]

Thank you for reporting the issue. We have raised an internal ticket to track this. Our service engineers will get back to you.

[nolancaster]

@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.

[lawa1974]

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.

[nolancaster]

I'm still trying to reproduce this and could use some more information:

1. Can you tell me if your tfstate file lists system tags for the instance?
2. Does the console show any system tags for the instance?
3. If you create a new instance and immediately try another tf apply do you see the same behavior?

[lawa1974]

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.

[nolancaster]

@lawa1974 I'm not having any luck reproducing this issue. If you could share your Terraform configuration for this instance that would be helpful.

[cam-mclaren]

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.

[cam-mclaren]

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"

    }
  }
}

[cam-mclaren]

A satisfactory solution might be found with this hashicorp/terraform#23814 but it involves modifying the provider so that the Computed: field in the resources schemas is set to false.

[eist76]

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.

[vGruntus]

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.

[cam-mclaren]

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 cam-mclaren@019c4d2 can resolve the issue.

[cam-mclaren]

PR For this issue has been raised #2137

[vGruntus]

FWIW, this issue still exists in 5.45.0.

[eist76]

still exists in 6.15.0

[vGruntus]

still exists in 6.15.0

@tf-oci-pub, could we please have an acknowledgement that this is still an issue, and whether the fix will be the provider or the API response?