Request for experimental attribute for Schema struct just like Deprecated

[ujjwal-ibm]

SDK version

v2.17.0

v2.17.0

Use-cases

Support for experimental features with a message just like in Depcreated

Attempted Solutions

"new_feature": {
							Type:             schema.TypeInt,
							Optional:         true,
							Computed:         true,
							Experimental:     "This field is an experimental field and behaviour is subject to change",
						},

Proposal

Support for change in field functionality with the experimental feature

References

[bflad]

Hi @ujjwal-ibm 👋 Thank you for raising this.

While it would be relatively straightforward to support something like this in a more generic form, there are some practitioner experience concerns that would then be created. In particular, the mechanism in which this functionality would have to rely on is creating an attribute-based warning diagnostic during validation if the field has a non-null configuration. Diagnostics are currently designed within Terraform as an issue-based feedback mechanism, which generally requires practitioner action, such as removing deprecated attributes from configurations.

Practitioners do not currently have the ability to disable/ignore warnings so it would show every Terraform operation, such as plan, apply, etc. This "warning" would also be generated across every instance of the "issue", potentially flooding the practitioner's plan. Terraform CLI does have the ability to perform some amount of diagnostic de-duplication, but it may not catch this particular usage since it could be spread across resource types and attribute names. Any potential feature request in this area would need to be handled upstream in Terraform CLI.

Some providers wishing to implement this type of functionality have opted for an environment variable based approach so practitioners can opt-out of the warnings, however the terraform-plugin-sdk Go module is unfortunately fairly limited in the ability to create this as a provider-defined behavior. A typical workaround in this type of "custom configuration validation" situation would be implementing a resource-level CustomizeDiff function which gets called during the plan phase, however that only accepts an error return and not diag.Diagnostics. There would need to be some prioritization efforts to discuss if offering a way to specify warning diagnostics during that already designed provider-defined logic is more desirable than potentially something at the schema-level.

The terraform-plugin-framework Go module, the next generation SDK for provider development, does support custom attribute validation hooks that can return warning diagnostics. It is possible to combine sdk and framework providers per-resource, however the documentation is not quite live for that yet.