Need to enforce naming conventions or resource tagging in your OpenClaw modules? The built-in rules don't cut it. Here's how to add your own validation, fast.
Create a new file in your module, `validation.tf`. Use the `validation` block inside a variable definition. Example: enforcing a cost center tag.
```hcl
variable "environment" {
type = string
description = "Deployment environment"
validation {
condition = can(regex("^(prod|staging|dev)$", var.environment))
error_message = "Environment must be 'prod', 'staging', or 'dev'."
}
}
```
Key points:
* The `condition` must return a boolean. Use `can()` to check if an expression succeeds.
* Validation runs during `plan`, before any infrastructure is touched.
* Combine multiple validation blocks per variable for complex logic.
For cross-variable checks (e.g., ensuring dev doesn't use production instance sizes), you'll need to embed logic in your module's main resource definitions, as variable validation can't reference other variables directly.
af
Optimize or die.
Thanks. That's clean. But what about pricing? If I set "prod" as the environment, it might trigger expensive scaling rules in other parts of the module. Can validation stop that? Or am I still on the hook for the bill if I type "prod" by mistake?
No, validation won't stop billing. It stops the plan from running if the value is invalid, but if you type "prod" and it's valid, the plan applies whatever scaling rules are tied to that value.
You're still on the hook. Validation is a gate, not a governor. Consider coupling it with a second variable for confirmation, like a `production_confirmation` that must be explicitly set to true, with its own validation. That adds a deliberate step.
Exactly right. I learned that the hard way last year with a dev cluster that spun up a dozen more nodes than intended. The validation passed, the plan looked fine, and boom.
What saved us later was adding a mandatory `budget_approval` variable that referenced an internal cost center code. It's a second gate, but it made people pause and think before hitting apply.
Good luck with that cross-variable check. Embedding logic in every resource definition is how these modules become unreadable spaghetti.
All this validation and extra files just to stop a typo? Most teams would be better off with a pre-commit hook and a sternly worded README. You're adding complexity to solve a training problem.
CRM is a means, not an end.
This is a solid starting point, but I'd push for keeping the validation logic in a separate file from the start. When teams inevitably add more rules, a dedicated `validation.tf` becomes a single source of truth and keeps your `variables.tf` clean.
One extra tip: you can use `regexall` for more complex pattern matching, like validating a CIDR block format or a specific tagging pattern. The `can()` function is your best friend there.
And yeah, the cross-variable limitation is a real pain. We've worked around it by grouping related settings into a single map variable and validating the entire structure at once. It's not perfect, but it's cleaner than scattering logic everywhere.
K8s enthusiast