Update: Ability to raise an error

Terraform
1

Hi everyone :blush:

This is a follow-up to our recent request for research examples regarding the ability to raise an error. We’ve just released a new feature for setting preconditions and postconditions in configuration, now available in terraform_1.2.0-alpha-20220328. To learn more and see use-cases, you can read our draft documentation (or see below for a quick introduction).

What are preconditions and postconditions?
Preconditions and postconditions allow you to write in configuration what conditions must be met before an apply can take place, define checks for correctness for values that are known at apply-time, and lets your surface errors early on during a plan if those conditions aren’t met. Error messages can be customized, and include relevant information about which part of a given value is invalid. These condition blocks can apply to resources, data sources, and outputs.

Preconditions and postconditions are also an expansion of our custom variable validation, and allow for more use-cases, such as:

  • You can reference variables, locals, other data objects, and a collection of values in the condition blocks.

  • For values that are unknown until apply time, Terraform can validate those values using postconditions.

  • Error messages include information about exactly which part of the given value is invalid, to help narrow down the source of a problem within a larger data structure.

How to provide feedback
We’d love any and all feedback on this feature, such as:

  • Usage reports: Does this feature work for you? How are you using it? Are there use-cases it doesn’t meet? These can be added as comments to this post.

  • Bug reports: For any bugs or crashes, you can create an issue.

We’re excited for you to try this out, and thank you in advance!

A special thank you to everyone who commented across Discuss and Reddit as well – your examples and workarounds were pivotal in designing this feature, and we’re so grateful for your time and investment in Terraform.

5 Likes
2

Thanks for the update, Korinne – looking forward to trying it out!

1 Like
3

Excited to get your thoughts, and thank you again for meeting with me to go over your use-cases!

4

This looks like an excellent implementation for raising errors; it makes sense to have it as a lifecycle item and re-use the validation techniques from the variable validators.

One thing I don’t see yet is the ability to raise a warning instead of an error, but I imagine that would make the implementation quite complex. The benefit would be the ability to deprecate features in shared modules and allow users of transitioning versions to still use what they are familiar with for a bit but then receive a warning about the pending deprecation.

For now, I’m going to try this precondition/postcondition out as soon as possible, looks like a much better method vs. my null resource way.

2 Likes
5

Hi, this is a really interesting use-case, and we’ve heard similar needs in the past. Would you be open to:

  • Filing an enhancement issue with the label [custom-conditions](Issues · hashicorp/terraform · GitHub). We’d love to keep track of this request for future improvements. This would also allow us to track how much interest in this feature there is in the community, and unearth any other requirements/use-cases.

  • Meeting with me on a call, to go over your setup and how you’d like to use such a feature. If you’d rather do so over email, we can work that out as well!

Thanks again for your feedback!

6

Hi all!

It might interest those following this topic to know that today we published a new alpha release v1.2.0-alpha20220413 which includes support for the precondition and postcondition block types without the requirement to explicitly opt in to the experiment.

This “graduation” to a non-experimental feature does represent that we feel based on feedback that the design of this feature is ready to ship and the scope of functionality for the first release is essentially settled, but please note that we do still reserve the right to change the design before v1.2.0 final if we get some significant feedback that justifies that.

Thanks for trying this out and sharing your experiences! We’d still love to hear feedback in all the same channels that @korinne mentioned above.

7

A post was split to a new topic: Are preconditions and postconditions available for modules?