Hi all For those that haven’t met me, I’m Korinne, and I’m the Product Manager for Terraform Core.
We’re currently researching the need for assertions in Terraform, and the ability to raise an error as well as stop a plan or apply from continuing if certain conditions are not met. There are several GitHub issues that request functionality similar to this [the most popular being this one], but as many are older issues, we wanted to open the floor for further requests around this topic.
If interested, I’d love to setup a call to go through your use-cases, and get more information about what kinds of problems this functionality would solve. With that, if you’d be open for a call, feel free to comment on this thread or DM me privately! If you’d rather not do a call, you can also comment any use-cases you’d like to see.
Hi Korinne!
Just wanted to share that I am still actively using a conditional call to file("ERROR: descriptive message of what somebody did wrong to get here") as I described in Ability to raise an error · Issue #15469 · hashicorp/terraform · GitHub . I’m not looking for any additional feature complexity, I just want a cleaner-looking way to do what I’m already doing, which is to emit a custom failure message for the human operator (under arbitrary conditions of my choosing).
Thanks,
David
Thank you, David! It’s helpful to know that your use-case is fairly straightforward. Let me know if you think of any other functionality you’d like to see, and thanks
Our shop makes use of >20 asserts across >100 modules using a malformed regex to cause a failure. E.g.:
locals {
...
assert_iops_set_if_storage_type_is_io1 = regex(
(local.storage_type == "io1" && local.iops == null) ?
"((Force invalid regex pattern)\n\nERROR: No IOPS set, yet storage type is io1" : "", "")
}
We would use them more, but the mechanism is awkward and the output can be confusing. (I see other potentially simpler mechanisms like with file("ERRROR: lorem ipsum"), but it’s still a workaround).
We’d be very much interested in a proper assert / error-raising mechanism, and I’d be happy to discuss details with you, @korinne.
Edit: To provide more context, many of our modules are used directly by our dev teams for provisioning specific infrastructure for their independent services beyond what our base platform provides (think RDS, Redis, S3 buckets, IAM, etc), so we have less Terraform-savvy folks calling these modules, and so we want to add more guardrails as possible, hence the need for asserts.
Hi everyone! I’m the proud author of the (now-stale ) PR for raise(<MESSAGE>)here and described in the issue here. Along my journey (first Go code contribution and first time contributor to HCL or Terraform), I found my MR actually should have targeted the Terraform repo rather than the HCL one, and I moved on to other projects before I had a chance to resubmit against the Terraform repo.
In summary though, regarding this feature, I did really like and would advocate for the simple raise(message) syntax for its simplicity and its compatibility with the try(), can() and inline if then statements. I’d still love this to be supported by Terraform and it would give a similar but much cleaner solution to the workaround mentioned by @dmrzzz above:
file(“ERROR: descriptive message of what somebody did wrong to get here”)
just becomes
raise(“descriptive message of what somebody did wrong to get here”)
I’m sure there are probably other approaches to explore - I’m actually very happy to hear this is potentially going to be picked up again. Eager to see where this thread goes and if we can add it in a future release.
Thank you for this really helpful information! I’ll send you a direct message to see if we could get on a call to go over other details, as I’m really curious about your workarounds and what kinds of requirements you’d need.
Your team setup/module workflow is fairly common, so you’re the exact person we’d like to make successful with a feature like this.
Hi, and thank you for bringing this to the community back then I’m also happy we’re researching this now. If you’d like to discuss further or in general provide Terraform feedback, I’d love to setup a call!
I use this all the time, often to validate multiple variable inputs (e.g. for mutually exclusive module variables, ensure that if one is set, none of the others are set) or to check conditions based on dynamic inputs (not possible with variable conditions).
For my assertion module, I used a call to a non-existent function as the mechanism for crashing Terraform, with the error message as an input argument to the non-existent function. This results in a reasonably nicely-formatted error message.
Similar to the other commenters, my needs are simple:
Takes an expression condition that you want to assert is true.
Takes a string error message that will be displayed if the expression evaluates to false.
Supports dynamic inputs (i.e. can reference locals, resource/data outputs, etc.), unlike the variable conditions, for both the expression and the error message.
Supports some form of count/for_each or equivalent (can dynamically specify multiple assertions without writing each out separately.
Hello !
I do have a simple use case that where I’m willing to have ability to fail with custom message.
To set up some ressources, I’m using objects stored in an aws s3 bucket.
These objects require a specific metadata (content-type: text/plain) for their body to be available in terraform (due to some limitations with binary data).
These objects are created manually and not through iac (it’s credentials)
In order to mitigate human error, I want to have a special check that ensure body is available once data is retrieved by terraform (otherwise body is null / empty string)
I use these data in a for_each, so If I don’t do anything, my plan / apply fails but doesn’t tell me which object is wrong.
As a workaround, I filter null values, but I add an output with all null values to help developers manually ensures this output is empty.
I would love the ability to tell terraform that if this output is not empty, it should throw a custom error message.
I’m currently using a null resource with a count to report errors using a bool that will either evaluate to 0 or to the error string which will then cause a failure.
In SaltStack I used to use things like the ‘test’ state (salt.states.test) which would be comparable to a test resource that you can use for similar purposes but is not as good as a raise() / raise { } option.
Ironically I’ve just come across this thread, a day after independently coming up with the “conditionally call an undefined function, in order to force an error” technique.
A simple error(message) function would fill a much-needed hole in the Terraform language.
Thank you for this additional feedback, and I’m glad you have a need for this feature! I’ll be sure to update this post when we have something to share, as a result from this research.
In the post, we discuss a new feature for defining preconditions and postconditions, now available in terraform_1.2.0-alpha-20220328. This feature was largely designed with all your use-cases and workarounds in mind, as well as requests for expanding our current variable validation use-cases. Thank you again for all of your help informing this feature – we are really thankful for your input, and hope this feature solves a core problem.
If you’d like to try the feature out, we’d love your feedback! Some of you I’ve met on calls, and I’d be happy to do so again if you’d like to discuss further.
For those that haven’t met me, I’m Korinne, and I’m the Product Manager for Terraform Core.
) PR for 
I’m also happy we’re researching this now. If you’d like to discuss further or in general provide Terraform feedback, I’d love to setup a call!