This is an automated email from the ASF dual-hosted git repository. sudo87 pushed a commit to branch fix/storage-range-import-project-displaytext in repository https://gitbox.apache.org/repos/asf/cloudstack-terraform-provider.git
commit 19a2d8a71ed516bd192e50c23db22658935706f2 Author: Manoj Kumar <[email protected]> AuthorDate: Fri Aug 28 15:54:23 2026 +0530 Document ForceNew-field footgun after cloudstack_service_offering import Investigated the reported destroy+recreate-on-import issue (#305): the importer's resulting state is actually fully hydrated correctly, because Terraform automatically calls Read (visible as "Refreshing state...") right after the custom importer function runs, which overwrites whatever partial state the importer itself set. So populating cpu_number/cpu_speed/ memory inside resourceCloudStackServiceOfferingImport would be a no-op — verified by importing a real lab offering with the unmodified importer and confirming cpu_number/cpu_speed/memory were already correct in state. The actual destroy+recreate happens because Terraform diffs the *config* (which a minimal post-import .tf typically leaves blank for these fields) against the now-correct state; since these fields are ForceNew, the config's implicit zero value differs from the real value and forces replacement. This is a doc/workflow gap, not a code bug: documented that all ForceNew fields must be fully specified in config after import. Verified empty terraform plan after import with a fully-specified config, and unchanged (still-forcing) plan with a minimal one, matching this explanation. --- website/docs/r/service_offering.html.markdown | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/website/docs/r/service_offering.html.markdown b/website/docs/r/service_offering.html.markdown index 6a5754f..f8feadf 100644 --- a/website/docs/r/service_offering.html.markdown +++ b/website/docs/r/service_offering.html.markdown @@ -109,3 +109,14 @@ $ terraform import cloudstack_service_offering.example <SERVICEOFFERINGID> *NOTE: The importer looks up the service offering by ID and resolves the required `name` attribute from it, so it does not need to be set in the configuration beforehand.* + +*WARNING: After import, the resource's state is refreshed with the imported +offering's actual `cpu_number`, `cpu_speed`, `memory`, and other `ForceNew` +attribute values. If your `.tf` configuration for the imported resource +leaves any of those `ForceNew` attributes unset, `terraform plan` will show +a destroy-and-recreate of the offering, since an unset attribute is treated +as its zero value and compared against the real imported value. After +importing, write out the full set of `ForceNew` attributes in your +configuration (matching the values shown by `terraform state show`) before +running `terraform plan`, or the plan may propose replacing a live, possibly +in-use offering.*
