Allow warning messages within variable validation

[derekwinters]

Terraform Version

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.

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 variables to ensure one was provided. Exit with error if both are empty strings.
  provided_name = coalesce(var.bucket_name, var.name)
  bucket_name   = var.bucket_name != "" ? join("-",[var.environment, local.provided_name]) : local.provided_name
}

Proposal

It would be useful to highlight the deprecated variables of a module within the Terraform plan. For this to work, it would need to be possible to choose warning or error for the validation.

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     = ""

  validation {
    condition     = var.name != ""
    error_message = "This variable has been deprecated, use bucket_name instead."
    error_level   = "warning"
  }
}

This would then trigger a warning message at the end of the plan, similar to provider warnings or variable validation errors.

Warning: Module Variable Condition

  on ../modules/example/variables.tf line 18:
   18: variable "name" {

This variable has been deprecated, use bucket_name instead.

This was checked by the validation rule at variables.tf:23.

References

No response

[crw]

Thanks for this feature request! If you are viewing this issue and would like to indicate your interest, please use the 👍 reaction on the issue description to upvote this issue. We also welcome additional use case descriptions. Thanks again!

[kmoe]

This sounds reasonable to me, given that the variables for a module form part of its public API.

[olenm]

I hope this request gets expanded for all constraints, not just within a module - as vars can come from the environment and having non-error warnings is often far superior than crash-and-burn checks.

[Samreay]

This would be a incredible for us - we're currently trying to standardise naming conventions and being able to add in a simple regex validation on inputs (for example, all lower case and dashes instead of underscores) without requiring everything to update at once would be amazing

[bschaatsbergen]

Hey @derekwinters,

Thanks for raising this issue. It seems you're suggesting two distinct features:

1. Deprecating input variables: This would allow module authors to gradually phase out old input variables, providing a smoother transition for module callers.
2. Warning diagnostics for custom conditions: This would enable module authors to issue warnings instead of hard errors for certain validation conditions, giving module authors more flexibility in their module interface.

Both ideas are valuable and worth exploring.

---

Note

For context, when I refer to a module’s "interface" I’m talking about its input variables and output values.

1. Deprecating input variables

We're currently prototyping support for deprecating input variables and outputs. This would provide a similar experience to deprecating provider resource arguments, allowing module authors to gradually phase out input variables and outputs and guide users towards newer, preferred options. You can track the progress of this feature in #36016.

2. Warning diagnostic for custom conditions

Currently, custom conditions in Terraform (like variable validation, preconditions, and postconditions) can only trigger error diagnostics. This can be limiting, as sometimes a warning might be more appropriate for a less critical validation failure.

To address this, we could introduce a warning_message argument in addition to the existing error_message argument. This would allow module authors to specify a warning message that would be displayed instead of an error, giving users more flexibility in handling validation failures.

Here’s an example:

variable "instance_type" {
  type = string
  validation {
    condition     = contains(["t2.micro", "t2.small", "t2.medium"], var.instance_type)
    warning_message = "Selected instance type may not handle heavy workloads."
  }
}

Alternatively, in a postcondition:

data "aws_instance" "example" {
  instance_id = "i-1234567890abcdef0"
  lifecycle {
    postcondition {
      condition     = data.aws_instance.example.public_ip != ""
      warning_message = "The instance has a public IP, potentially exposing it to the internet."
    }
  }
}

Drawbacks of warning diagnostic for custom conditions

• Overusing warnings can desensitize users, making it harder to identify important issues. Practitioners tend to ignore warnings until they turn to errors.

Next steps

I'll discuss this proposal with the team to get their feedback and explore a potential implementation. Thanks again for raising this issue. Let's continue the conversation!

[Audiopolis]

Warnings are common in all sorts of things. Loggers, missing extras in packages, imports of dependencies of dependencies (not in your pyproject.toml), wet floors...

If you ignore warnings, you get what's coming. I want to warn about unconventional or "could fail in some situations" configurations, or "this configuration won't support xyz functionality" without preventing the user from doing those dangerous things. Maybe they're just setting up a quick, dirty, cheap development environment and don't care.

In my IDE (PyCharm), missing Terraform variables are presented as strong warnings in the code (yellow highlighting), and errors on plan/apply. A warning would ideally result in a weak warning (zigzag line), and on plan/apply, a printed, very visible warning.

It's a big request for sure, but even just printing a yellow warning on plan/apply would be enough to catch or ignore problems based on the strictness of the company/CI.