-
Notifications
You must be signed in to change notification settings - Fork 9.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Preconditions and Postconditions #30401
Conversation
9043ebd
to
ba06388
Compare
This construct of a block containing a condition and an error message will be useful for other sorts of blocks defining expectations or contracts, so we'll give it a more generic name in anticipation of it being used in other situations.
This allows precondition and postcondition checks to be declared for resources and output values as long as the preconditions_postconditions experiment is enabled. Terraform Core doesn't currently know anything about these features, so as of this commit declaring them does nothing at all.
If a resource or output value has a precondition or postcondition rule then anything the condition depends on is a dependency of the object, because the condition rules will be evaluated as part of visiting the relevant graph node.
ba06388
to
904bb28
Compare
If the configuration contains preconditions and/or postconditions for any objects, we'll check them during evaluation of those objects and generate errors if any do not pass. The handling of post-conditions is particularly interesting here because we intentionally evaluate them _after_ we've committed our record of the resulting side-effects to the state/plan, with the intent that future plans against the same object will keep failing until the problem is addressed either by changing the object so it would pass the precondition or changing the precondition to accept the current object. That then avoids the need for us to proactively taint managed resources whose postconditions fail, as we would for provisioner failures: instead, we can leave the resolution approach up to the user to decide. Co-authored-by: Alisdair McDiarmid <alisdair@users.noreply.github.com>
This is not currently gated by the experiment only because it is awkward to do so in the context of evaluationStateData, which doesn't have any concept of experiments at the moment.
904bb28
to
cdae6d4
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We also need to verify that there are no self-references via a full address in these blocks, as that will bypass the self
check in preconditions and possibly cause cycles to crop up during apply. This otherwise LGTM if you want to tackle that extra validation in a separate PR.
Thanks! Good catch, and I'll handle that in a follow-up PR for easier review. |
Reminder for the merging maintainer: if this is a user-visible change, please update the changelog on the appropriate release branch. |
I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active contributions. |
This PR introduces two new concepts to help document expectations and assumptions about resources, data sources, and outputs. By specifying
precondition
andpostcondition
blocks, module authors can define explicit checks which must betrue
for the configuration to be valid.Preconditions are checked before creating a resource, reading a data source, or recording a module output value. These can be thought of as documented assumptions about the referenced data, which are checked by Terraform on every plan and apply. Preconditions can refer to values elsewhere in the configuration (which may cause Terraform to reorder the operations on those dependencies).
Postconditions are checked after creating a resource or reading a data source. As such, they may refer to values in the resource or data source directly. These can be thought of as assertions about the referenced data, ensuring that the module adheres to an explicit contract.
In configuration, preconditions and postconditions look a lot like custom variable validation rules, and in fact use the same underlying code. Here's a brief example:
For more examples and further background, see the included documentation page.
This PR is a rebase and update of #27008, and as such most of the code was written by @apparentlymart, apart from the bugs which are probably mine.