Allow warning messages within variable validation
### Terraform Version ```shell Terraform v1.3.7 ``` ### Use Cases I want to be able to raise a warning in a Terraform module, similar to how a provider raises a warning for deprecated arguments. We focus heavily on maintaining backwards compatibility and giving time to transition how modules are used, so we end up deprecating module variables in favor of new variables from time to time. We document this in variable descriptions and the logic that uses them handles the logic for transitioning, but being able to clearly highlight the deprecations in the plan would be very useful as well. ### Attempted Solutions The way we accomplish this today is simply in descriptions, readme/documentation, and in the implementation of the variables. As a highly simplified example, we may want to change the name of a variable as we update legacy modules to use standard variable name structures and input types across all our modules. ```hcl variable "name" { description = "The name of the bucket to create. DEPRECATED: Use bucket_name instead. If bucket_name is provided, this string is ignored." type = string default = "" } variable "bucket_name" { description = "The unique name of the bucket to create. This will be combined with the environment name to create the final bucket name." type = string default = "" } variable "environment" { description = "The environment name for this resource." type = string } locals { # Compare two variabl
Posted by derekwinters on Jan 27, 2023, 10:38 PM
Tags
Related issues
- struct's lifetime requirements can be bypassed via covariant field assignment
- Proposal to Reorganize the Moderation Team and Review Moderation Policies
- Progressive FPS degradation appears to be related to dota2.com — blocking the domain prevents the performance loss
- proposal: container/...: generic collection types
- Better Custom Endpoint BYOK
- A concrete policy for backward compatibility until Godot 5.0
Raise real-world problems, find people facing the same issue, and discuss solutions.2,500 issues0 comments
github (Other)
struct's lifetime requirements can be bypassed via covariant field assignment
Proposal to Reorganize the Moderation Team and Review Moderation Policies
Progressive FPS degradation appears to be related to dota2.com — blocking the domain prevents the performance loss
proposal: container/...: generic collection types
Better Custom Endpoint BYOK
A concrete policy for backward compatibility until Godot 5.0
New MTP models not supported
Tracking: 429 / Capacity Issues
Allow warning messages within variable validation
### Terraform Version ```shell Terraform v1.3.7 ``` ### Use Cases I want to be able to raise a warning in a Terraform module, similar to how a provider raises a warning for deprecated arguments. We focus heavily on maintaining backwards compatibility and giving time to transition how modules are used, so we end up deprecating module variables in favor of new variables from time to time. We document this in variable descriptions and the logic that uses them handles the logic for transitioning, but being able to clearly highlight the deprecations in the plan would be very useful as well. ### Attempted Solutions The way we accomplish this today is simply in descriptions, readme/documentation, and in the implementation of the variables. As a highly simplified example, we may want to change the name of a variable as we update legacy modules to use standard variable name structures and input types across all our modules. ```hcl variable "name" { description = "The name of the bucket to create. DEPRECATED: Use bucket_name instead. If bucket_name is provided, this string is ignored." type = string default = "" } variable "bucket_name" { description = "The unique name of the bucket to create. This will be combined with the environment name to create the final bucket name." type = string default = "" } variable "environment" { description = "The environment name for this resource." type = string } locals { # Compare two variabl
Comments (0)
No comments yet. Start the discussion.