Handling a null response for certain values from PCA

[cam-mclaren]

This PR should resolve #1923
This PR should resolve #1924

Oracle Private Cloud Appliances 3.0 are designed to be API compatible with Oracle Cloud. However the Appliances have no concept of system_tags and return a null value to the Golang SDK functions. This results in Terraform plans that constantly report a (known after apply change) for system_tags.

There is similar behavior for the extended_metadata

By adding logic to appropriately convert null values in API responses to empty maps {} the terraform-provider-oci provider will become much more usable for customers using it to manage Private Cloud Appliances.

[tf-oci-pub]

Thank you for your valuable contribution. We greatly appreciate your efforts in submitting this pull request. However, I regret to inform you that we are unable to merge it directly on GitHub at this time.

Our internal policy requires that all pull requests undergo thorough local testing and review before they can be merged into the main codebase. This process ensures the quality and stability of Terraform-Provider-OCI.

We understand that this may cause some inconvenience, but please rest assured that your contribution is highly valued. Our team will carefully review and test your changes locally to ensure they meet our standards.

We appreciate your understanding and patience in this matter. If you have any questions or need further assistance, please don't hesitate to reach out. Thank you once again for your contribution.

[tf-oci-pub]

Why does setting the values to an empty map fix the issue you are facing?

[cam-mclaren]

Hi thanks for reviewing.

Problem Description

At the moment we are having trouble with aggregate data types like maps being returned as null by the PCA API. When stored as null in the state file these aggregate data type variables report a change as being required every plan despite the values not being specified in our terraform configuration.

To give a concrete example, below I have an image of the state file for vm instance created with the OCI Terraform provider on a Private Cloud Appliance. You can see that the value for system tags is set to null which is due to the behavior of the PCA API.

Image 1: system_tags set to null

Whenever this system_tags variable is set to null in the state file a terraform plan will always report (known after apply) as the value it will be changed to. With the null value Terraform seems to always detect changes to be made despite no actual Terraform configuration changes. This is okay when dealing with a single vm instance. However larger scales these reported changes become very problematic and make it very difficult to determine legitimate drift in your configuration.

Image 2: terraform plan reports the system_tags value as requiring a change despite its value being unspecified.

We can fix this false system_tags change by setting it to an empty map {} through a manual edit of the state file. Below I have an image of the state file after being manually edited.

Image 3: system_tags is manually set to {} in the state file.

The resulting terraform plan no longer reports the system_tags attribute as requiring a change as can be seen in Image 4.

Image 4: There is no required change detected for system_tags.

We can fix the extended_metadata attribute in the same way. By changing it in the state file from null to {} this will remove the false change from the plan entirely.

Image 5: After setting the values in the state file from null to {} no change is detected.

As seen above setting the values of extended_metadata and system_tags to a value of empty map entirely removes the problem of the provider falsely reporting changes for PCA users.

I suspect for those without a PCA to access you will be able to confirm this problematic behavior from null by manually editing a state file for a vm instance on OCI so that its system_tags attribute is set to null.

[cam-mclaren]

Sorry my reply was a little verbose. Does it answer the question or have I misunderstood the direction of your query?

[samktan]

I use OKIT with my PCA X9 and I can confirm that the problem here is that "null" <> "null", hence when the OCI provider returns NULL, TF thinks that there is a change / update required. Return {} "empty" is better because {} == {} hence TF knows that there was no change. I would support this merge.

[vGruntus]

Given that this issue has been known for nearly a year, and this PR was submitted nearly six weeks ago, could we please at least have a response to this @tf-oci-pub? This is a major headache for anyone using Terraform to manange their very expensive Private Cloud Appliances.

[samktan]

I strongly approve this change and would like to request it progress to merging and further testing. Can someone please integrate this change?

[eist76]

@tf-oci-pub can an we please get this reviewed and merged? very annoying behavior for anybody using terraform with oci.

[eist76]

is there any update on this? with version 6.15.0 this annoying issue is still out there for all Oracle PCA customers ....

although there are NO changes, every single time terraform wants to update system_tags and extended_metadata ....

  # oci_core_instance.instance["xxx.xxx.com"] will be updated in-place
  ~ resource "oci_core_instance" "instance" {
      + extended_metadata           = (known after apply)
        id                          = "ocid1.instance.XXX.xxx.xxxxx7tuclogsg2cgdeanyutsn3d52rne1cthuxxmtb9b5vkn7ovuo7b5t"
      + system_tags                 = (known after apply)
        # (21 unchanged attributes hidden)

        # (6 unchanged blocks hidden)
    }