helper/resource: Try to Remove id Attribute Requirement #84
Comments
|
Setting up unit testing of this will likely require some terraform-plugin-go code under |
|
The In fact, that does seem to be where the error message you mentioned is coming from: I suppose it might work to just let that be missing or empty and to leave the With that said: it seems kinda awkward to force testing for modern providers to still run through the old SDK shims, because the shims are inherently lossy: we need to reduce everything into flatmap. Do you think it would be plausible to add a new field alongside the legacy Since the error you referred to seems to belong to the shims, I'm expecting that skipping running the shims altogether would effectively skip any legacy codepath that thinks I suppose a key downside is that we have written various helper functions with the signature defined in |
We have plans over the next few months to investigate and implement the next iteration of provider testing. That project, which wouldn't be reflected in this codebase, has a lot of considerations already so that seems like a more appropriate time for introducing larger changes rather than trying to reflect them as part of a targeted effort to try clearing up this particular attribute requirement. Unless, of course, those shims are a major blocker towards this effort and we decide that fixing this is worth potentially burdening provider developers twice with changes (once to update existing |
|
With the introduction of the terraform-plugin-testing module (migration guide), we are transferring feature requests relating to the |
|
Is there any update? Are there any recommendations how to circumvent the test braking? |
|
@ArnoSen no updates at the moment. Please refer to the framework testing documentation for example code to implement the |
|
Thanks for the swift response. |
Terraform will remove the attribute and its value from state once the change is applied. Any configuration references or other usage of the non-existent attribute will raise validation errors before it can be planned/applied.
If you have no real world use for an |
…rement Reference: #84 The resource instance state identifier was a Terraform versions 0.11 and earlier concept which helped core and the then SDK determine if the resource should be removed and as an identifier value in the human readable output. This concept unfortunately carried over to the testing logic when the testing logic was mostly changed to use the public, machine-readable JSON interface with Terraform, rather than reusing prior internal logic from Terraform. Using the `id` attribute value for this identifier was the default implementation and therefore those older versions of Terraform required the attribute. This is no longer necessary after Terraform versions 0.12 and later. This testing logic only supports Terraform version 0.12.26 and later. The remaining resource instance identifier and `id` attribute usage in the testing logic was: - When the `TestStep` type `ImportStateVerify` field is enabled, the instance state identifier between prior resource state and import resource state are compared to find the correct resource. - When the `TestStep` type `ImportStateIdFunc` and `ImportStateId` fields are empty as the import ID for calling `terraform import` command. - Other various `terraform` package references For the first case, a new `TestStep` type `ImportStateVerifyIdentiferAttribute` field is added, which defaults to the prior `id` attribute. This preserves the existing behavior while enabling developers to choose a different identifier attribute if omitted from the resource so they can still use the `ImportStateVerify` functionality. For the second case, developers can use the `ImportStateId*` fields to choose/create the correct import identifier value. For the final cases, no action is needed as the `terraform` package is not intended for external usage and any usage of this identifer is mainly for equality and printing debugging information which is not accessed by the testing logic. These functions will be marked with Go documentation deprecation comments in a subsequent change.
…rement Reference: #84 The resource instance state identifier was a Terraform versions 0.11 and earlier concept which helped core and the then SDK determine if the resource should be removed and as an identifier value in the human readable output. This concept unfortunately carried over to the testing logic when the testing logic was mostly changed to use the public, machine-readable JSON interface with Terraform, rather than reusing prior internal logic from Terraform. Using the `id` attribute value for this identifier was the default implementation and therefore those older versions of Terraform required the attribute. This is no longer necessary after Terraform versions 0.12 and later. This testing logic only supports Terraform version 0.12.26 and later. The remaining resource instance identifier and `id` attribute usage in the testing logic was: - When the `TestStep` type `ImportStateVerify` field is enabled, the instance state identifier between prior resource state and import resource state are compared to find the correct resource. - When the `TestStep` type `ImportStateIdFunc` and `ImportStateId` fields are empty as the import ID for calling `terraform import` command. - Other various `terraform` package references For the first case, a new `TestStep` type `ImportStateVerifyIdentiferAttribute` field is added, which defaults to the prior `id` attribute. This preserves the existing behavior while enabling developers to choose a different identifier attribute if omitted from the resource so they can still use the `ImportStateVerify` functionality. For the second case, developers can use the `ImportStateId*` fields to choose/create the correct import identifier value. For the final cases, no action is needed as the `terraform` package is not intended for external usage and any usage of this identifer is mainly for equality and printing debugging information which is not accessed by the testing logic. These functions will be marked with Go documentation deprecation comments in a subsequent change.
…rement Reference: #84 The resource instance state identifier was a Terraform versions 0.11 and earlier concept which helped core and the then SDK determine if the resource should be removed and as an identifier value in the human readable output. This concept unfortunately carried over to the testing logic when the testing logic was mostly changed to use the public, machine-readable JSON interface with Terraform, rather than reusing prior internal logic from Terraform. Using the `id` attribute value for this identifier was the default implementation and therefore those older versions of Terraform required the attribute. This is no longer necessary after Terraform versions 0.12 and later. This testing logic only supports Terraform version 0.12.26 and later. The remaining resource instance identifier and `id` attribute usage in the testing logic was: - When the `TestStep` type `ImportStateVerify` field is enabled, the instance state identifier between prior resource state and import resource state are compared to find the correct resource. - When the `TestStep` type `ImportStateIdFunc` and `ImportStateId` fields are empty as the import ID for calling `terraform import` command. - Other various `terraform` package references For the first case, a new `TestStep` type `ImportStateVerifyIdentiferAttribute` field is added, which defaults to the prior `id` attribute. This preserves the existing behavior while enabling developers to choose a different identifier attribute if omitted from the resource so they can still use the `ImportStateVerify` functionality. For the second case, developers can use the `ImportStateId*` fields to choose/create the correct import identifier value. For the final cases, no action is needed as the `terraform` package is not intended for external usage and any usage of this identifer is mainly for equality and printing debugging information which is not accessed by the testing logic. These functions will be marked with Go documentation deprecation comments in a subsequent change.
…rement Reference: #84 The resource instance state identifier was a Terraform versions 0.11 and earlier concept which helped core and the then SDK determine if the resource should be removed and as an identifier value in the human readable output. This concept unfortunately carried over to the testing logic when the testing logic was mostly changed to use the public, machine-readable JSON interface with Terraform, rather than reusing prior internal logic from Terraform. Using the `id` attribute value for this identifier was the default implementation and therefore those older versions of Terraform required the attribute. This is no longer necessary after Terraform versions 0.12 and later. This testing logic only supports Terraform version 0.12.26 and later. The remaining resource instance identifier and `id` attribute usage in the testing logic was: - When the `TestStep` type `ImportStateVerify` field is enabled, the instance state identifier between prior resource state and import resource state are compared to find the correct resource. - When the `TestStep` type `ImportStateIdFunc` and `ImportStateId` fields are empty as the import ID for calling `terraform import` command. - Other various `terraform` package references For the first case, a new `TestStep` type `ImportStateVerifyIdentiferAttribute` field is added, which defaults to the prior `id` attribute. This preserves the existing behavior while enabling developers to choose a different identifier attribute if omitted from the resource so they can still use the `ImportStateVerify` functionality. For the second case, developers can use the `ImportStateId*` fields to choose/create the correct import identifier value. For the final cases, no action is needed as the `terraform` package is not intended for external usage and any usage of this identifer is mainly for equality and printing debugging information which is not accessed by the testing logic. These functions will be marked with Go documentation deprecation comments in a subsequent change.
…ction Reference: hashicorp/terraform-plugin-testing#84 terraform-plugin-testing version 1.5.0 and later will no longer require managed resources and data resources to implement the `id` attribute.
…rement (#164) Reference: #84 The resource instance state identifier was a Terraform versions 0.11 and earlier concept which helped core and the then SDK determine if the resource should be removed and as an identifier value in the human readable output. This concept unfortunately carried over to the testing logic when the testing logic was mostly changed to use the public, machine-readable JSON interface with Terraform, rather than reusing prior internal logic from Terraform. Using the `id` attribute value for this identifier was the default implementation and therefore those older versions of Terraform required the attribute. This is no longer necessary after Terraform versions 0.12 and later. This testing logic only supports Terraform version 0.12.26 and later. The remaining resource instance identifier and `id` attribute usage in the testing logic was: - When the `TestStep` type `ImportStateVerify` field is enabled, the instance state identifier between prior resource state and import resource state are compared to find the correct resource. - When the `TestStep` type `ImportStateIdFunc` and `ImportStateId` fields are empty as the import ID for calling `terraform import` command. - Other various `terraform` package references For the first case, a new `TestStep` type `ImportStateVerifyIdentiferAttribute` field is added, which defaults to the prior `id` attribute. This preserves the existing behavior while enabling developers to choose a different identifier attribute if omitted from the resource so they can still use the `ImportStateVerify` functionality. For the second case, developers can use the `ImportStateId*` fields to choose/create the correct import identifier value. For the final cases, no action is needed as the `terraform` package is not intended for external usage and any usage of this identifer is mainly for equality and printing debugging information which is not accessed by the testing logic. These functions will be marked with Go documentation deprecation comments in a subsequent change.
…ction (#830) Reference: hashicorp/terraform-plugin-testing#84 terraform-plugin-testing version 1.5.0 and later will no longer require managed resources and data resources to implement the `id` attribute.
|
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. |
SDK version
Use-cases
Providers written using terraform-plugin-go and terraform-plugin-framework do not require an
idschema attribute, nor is it required by Terraform or the protocol. There are legacy reasons why terraform-plugin-sdk requires theidattribute but maybe that can be removed from the testing framework. This would prevent those providers from needing to declare placeholderidattributes in their schemas to prevent this type of error:Then needing to discover the callout in the documentation.
Attempted Solutions
Placeholder
idschema attributes.Proposal
See if we cannot convince the legacy Terraform resource state handling underlying helper/resource that it is okay that we do not have an
idschema attribute.References
The text was updated successfully, but these errors were encountered: