helper/schema: Add Resource type flags for disabling legacy type system protocol flags
#1229
Conversation
There was a problem hiding this comment.
Switching the pull request view to ignore whitespace changes should make this file's changes easier to review (TestPlanResourceChange was switched to table-driven testing). 👍
This comment was marked as outdated.
This comment was marked as outdated.
…stem protocol flags Reference: #1227 Introduces new `Resource` type `EnableLegacyTypeSystemApplyErrors` and `EnableLegacyTypeSystemPlanErrors` fields that prevent the `PlanResourceChange` and `ApplyResourceChange` protocol operation responses from setting the `UnsafeLegacyTypeSystem` flag. When Terraform encounters the `UnsafeLegacyTypeSystem` flag, it will demote certain data consistency issues from error diagnostics that would immediately prevent Terraform workflows from completing to warning logs, which can be difficult for provider developers to discover. Provider developers are not generally expected to try enabling these settings unless discovering these data consistency issues upfront is desired before migrating resources to terraform-plugin-framework. This setting is on the individual resource level because these errors can be quite prevalent in existing terraform-plugin-sdk resources and therefore it would be problematic to not give provider developers more control over the behavior. The settings are split between plan and apply because the protocol flag is on two separate protocol operations and because certain errors for one operation may be unavoidable, so it leaves provider developers the option to still raise errors for the other operation. This change set includes new website documentation to discuss these data consistency issues and how to potentially resolve them more in-depth. It is expected that the framework migration guide will be updated to recommend enabling these settings before migrating to help provider developers understand existing issues before migrating. The error resolution section has one particular error to start and it is expected that this section will grow over time as provider developers report the various data consistency errors that Terraform can raise.
bflad
force-pushed
the
bflad/legacy-type-system-env-var
branch
from
2bbfe8e
to
405f5b2
Compare
|
|
||
| The state value check will raise an error if there is an unexpected value difference, which is the same as if Terraform raised the error. Checking state values of configured values can be removed once the resource is [migrated to terraform-plugin-framework](/terraform/plugin/framework/migrating), as Terraform itself will raise any potential error. | ||
|
|
||
| ## Resolving Data Consistency Errors |
There was a problem hiding this comment.
Not sure we need to open the can of worms in this PR, but should we eventually add the other common error planned value <blah> does not match config value <blah> or prior value to this section?
There was a problem hiding this comment.
Yeah, that would eventually be my goal from the PR description. I just don't have all those various errors handy right now and we'll need to figure out how we best want to discuss each one.
There was a problem hiding this comment.
Sorry! I missed that part of your PR description 😵💫
… migration guide Reference: hashicorp/terraform-plugin-sdk#1229
… migration guide (#819) Reference: hashicorp/terraform-plugin-sdk#1229 Co-authored-by: Benjamin Bennett <ben.bennett@hashicorp.com>
|
I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active contributions. |
Closes #1227
Introduces new
ResourcetypeEnableLegacyTypeSystemApplyErrorsandEnableLegacyTypeSystemPlanErrorsfields that prevent thePlanResourceChangeandApplyResourceChangeprotocol operation responses from setting theUnsafeLegacyTypeSystemflag. When Terraform encounters theUnsafeLegacyTypeSystemflag, it will demote certain data consistency issues from error diagnostics that would immediately prevent Terraform workflows from completing to warning logs, which can be difficult for provider developers to discover. Provider developers are not generally expected to try enabling these settings unless discovering these data consistency issues upfront is desired before migrating resources to terraform-plugin-framework.This setting is on the individual resource level because these errors can be quite prevalent in existing terraform-plugin-sdk resources and therefore it would be problematic to not give provider developers more control over the behavior.
The settings are split between plan and apply because the protocol flag is on two separate protocol operations and because certain errors for one operation may be unavoidable, so it leaves provider developers the option to still raise errors for the other operation.
This change set includes new website documentation to discuss these data consistency issues and how to potentially resolve them more in-depth. It is expected that the framework migration guide will be updated to recommend enabling these settings before migrating to help provider developers understand the issues before migrating. The error resolution section has one particular error to start and it is expected that this section will grow over time as provider developers report the various data consistency errors that Terraform can raise.