fix(product_enablement): avoid unexpected diff #689
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
A specific logic flow scenario in the TF provider is causing the
product_enablement
block to be displayed to customers as a resource that is going to be deleted (as part of their plan’s diff output) which is confusing as most customers are not expecting to see it and have no idea what theproduct_enablement
block is.The reason this happens is because the TF provider has logic to handle fixing drift in service versions (e.g. a user makes changes outside of Terraform). If, for example, a customer clones their service version outside of Terraform and activates a change separate from the TF provider, then this will cause the TF provider to call all Fastly APIs to see what has changed.
This consequently means the Product Enablement API is called and the local TF state is updated to include a
product_block
and thus a diff that shows the same block being deleted (because the user doesn’t have that block defined in their TF config file) is displayed as part of the plan’s diff output.To avoid this we only call the Fastly API for Product Enablement during the TF provider's READ operation if this block already exists within the user's local state (i.e. they've successfully applied a plan with
product_enablement
explicitly defined in their Terraform configuration file) OR if it exists in their state PLUS an import or resync of data is required.