Elastic cloud provider version 0.8.0 adding apm_secret_token everytime pipeline runs

[lukaszkowalczyk98]

I have recently upgraded the Elastic Terraform provider from version 0.4.1 to 0.8.0 and encountered an unexpected issue during the process. After successfully importing the ec_deployments resources, I performed a plan to verify the upgrade, but I noticed that the creation of apm_secret_token is pending in the plan. Surprisingly, this situation persists even after a successful apply.

Upon further investigation, I noticed that the apm_secret_token value is not being written to my state file during the apply process, and it remains set to the default value, i.e., null. This issue seems to be specific to clusters where the Integrations Server (APMs) feature is enabled.

I am using Terraform version 1.5.

Readiness Checklist

• I am running the latest version
• I checked the documentation and found no answer
• I checked to make sure that this issue has not already been filed
• I am reporting the issue to the correct repository (for multi-repository projects)

Expected Behavior

I expect that this vale of apm_secret_key will be added to my terraform state file and won't be pending in plan constantly.

Current Behavior

Steps to Reproduce

1. Create a ec_deployment resource with elastic provider 0.4.1 and add integrations_server configuration
2. Upgrade provider from 0.4.1 to 0.8.0
3. Import ec_deplotment and apply changes
4. Make terraform plan again

Context

We are trying to upgrade from elastic provider 0.4.1 to 0.8.0

Your Environment

• Version used: v0.8.0
• Running against Elastic Cloud SaaS or Elastic Cloud Enterprise and version: Elastic Cloud SaaS 8.8.2

[tobio]

Whilst we can fix the endless diff loop, this value is only returned by the API during resource creation, we're not able to set this value to a useful value.

To avoid this in 0.8.0 you could manually edit state, populating this with a non-null value. I'll look at avoiding the diff when the value is null as well.

In practice, usage of this field is potentially error prone in integrations_server resources. I'm going to open an issue to deprecate it and eventually remove it from integrations_server resources entirely.