Always show and store planned actions and checks even when planning fails #32395
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
For some kinds of plan failure we will already have successfully completed planning for at least one upstream object before encountering a downstream error. Since a downstream failure can be caused by an already-recorded action from upstream, it might be helpful to inspect the actions planned so far in order to understand better why the error occurred. This doesn't yet make this result visible anywhere, and is backward compatible with existing callers because they currently entirely ignore the returned plan pointer if the diagnostics contains at least one error.
In any situation where we return a plan object along with some errors we'll also explicitly annotate the plan object as being errored so that we can catch if someone accidentally tries to apply that incomplete plan. At the moment this situation is impossible to reach but in a later commit we'll make it possible to save errored plans to disk for further inspection, at which point it'll become important to not allow applying them.
This is a prototype of how the CLI layer might make use of Terraform Core's ability to produce a partial plan if it encounters an error during planning, with two new situations: - When using local CLI workflow, Terraform will show the partial plan before showing any errors. - "terraform plan" has a new option -always-out=..., which is similar to the existing -out=... but additionally instructs Terraform to produce a plan file even if the plan is incomplete due to errors. This means that the plan can still be inspected by external UI implementations. This is just a prototype to explore how these parts might fit together. It's not a complete implementation and so should not be shipped. In particular, it doesn't include any mention of a plan being incomplete in the "terraform show -json" output or in the "terraform plan -json" output, both of which would be required for a complete solution.
Make writing a plan file the default. We already create plans which have no changes so the plan result would need to be checked in automation, so having plans with errors should not pose a problem. If we find workflows which cannot handle a plan that can't be applied, we can reevaluate the need for a specialized flag. In the meantime, it feels more logical that the plan output would always describe the result of the plan, even if that included errors.
The status in the face of errors didn't matter before, because we never wrote out a plan with errors.
alisdair
approved these changes
Jan 4, 2023
| // include errors, because we intentionally try to show a partial plan | ||
| // above even if Terraform Core encountered an error partway through | ||
| // creating it. | ||
| op.ReportResult(runningOp, diags) | ||
|
|
||
| if !runningOp.PlanEmpty { | ||
| op.View.PlanNextStep(op.PlanOutPath) |
There was a problem hiding this comment.
Should we still call this "next step" view function even if the plan errored? Maybe we should pass the errored status (or the entire plan) to the function so that it doesn't say "you can apply this saved plan".
There was a problem hiding this comment.
PlanEmpty isn't set if there are errors, so keeps the zero value and this won't be called. There's still some more refinement to do in the CLI around errors, so we may need to revisit this anyway, but for now it doesn't interfere with the POC.
|
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. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Continuing on from where #31057 left off:
Some planning errors are caused by values planned successfully upstream, and so showing the partial plan created so far might potentially provide some relevant context to help understand the error message being reported.
Without showing this, today Terraform provides no way to inspect the actions planned so far, because they don't persist anywhere once Terraform exits.
After encountering an error, Terraform will now always attempt to write out a plan file with what was planned so far. This is especially useful when the failures were due to condition checks in the configuration, so that the changes recorded can be inspected to help the user determine why the conditions may have started failing.
The plan itself is marked as
erroredand cannot be applied, but can be inspected withterraform show -json planfile.This is a preliminary PR for initial integration testing. The CLI cannot yet re-render a plan with an error aside from the json representation.