Support of deprecation warnings for parameters with unknown values in `terraform validate`

[patrickcping]

Module version

v1.4.0

Use-cases

Detect and alert programmatically on use of deprecated provider parameters in HCL code stored in Github/Gitlab using CI actions.

HCL code may drift over time as >= or ~> notation is used in the provider/module version constraints. The action would alert to the use of a deprecated provider parameter if a provider version is upgraded

Attempted Solutions

• terraform validate --json - Cannot be used as deprecated parameters in the configuration HCL with unknown values (values determined after terraform apply) are not returned as warnings. E.g., a value that comes from a data source, used as a reference to a deprecated parameter on a resource will not show as a warning here
• terraform plan - Same as above, unless previously applied.
• terraform apply - Warnings are aggregated and limited and there doesn't appear to be a way to extract them as a full list in JSON. Also, infrastructure shouldn't need to be provisioned to warn about the use of deprecated attributes in the HCL.

Note that because of the above, the warnings returned by terraform validate are a subset of warnings returned from terraform apply

Proposal

Without knowing details of the Terraform architecture, the ideal situation would be for terraform validate --json to return use of deprecated attributes declared in the HCL, even if the values are unknown

References

• Moved from https://github.com/hashicorp/terraform/issues/33939

[bflad]

Hi @patrickcping 👋 Thank you for filing this and apologies for the delayed response.

There's a little bit of history here, which might be helpful to read through first to understand the current terraform-plugin-sdk and terraform-plugin-framework behavior: https://github.com/hashicorp/terraform/issues/31730

In short, since configuration validation occurs in Terraform without fully evaluating all values, even if they appear to be known (null or a value), practitioners can/will receive false positives in some cases. Providers are only receiving those configuration values as Terraform sends them, e.g. there is no special marking across the protocol to know whether a practitioner wants all possible usage of a deprecated attribute (even if eventually null) to conditionalize the warning logic on unknown values.

As a provider developer, you can however implement your own configuration validation logic which treats unknown values the same as known values if you wish. The attribute validation documentation describes how to write your own validator for this purpose, which you would then add to the schema for the desired attributes.

That said, I'm hesitant to believe that we would potentially adjust the existing deprecation logic for unknown values since practitioners seem to prefer the current behavior based on Terraform's data handling in this situation. We can however leave this open to capture whether folks might want an "official" configuration validator implementation that raises a warning on unknown values, via 👍 on the original issue description.

[bflad]

Normally by this amount of time this issue would likely be closed as there has been no additional upvotes or commentary on this issue, however one thing that has occurred since this was raised was that the Terraform type system added the ability for unknown values to be refined as partially unknown. One of those refinements is that an unknown value is "definitely not null" which would be extremely beneficial in this case. This is a large type system capability that will require an initial framework implementation and then take time for provider developers to properly implement across the provider ecosystem, but once available and practitioners are using the Terraform version with that functionality, it is plausible that the framework's deprecation logic could check for this additional condition before returning without a warning.

I'm going to leave this feature request open to track that exact enhancement. 👍