Use saved plan to determine CreateBeforeDestroy status #26192
Merged
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
A provider cannot influence CreateThenDelete vs DeleteThenCreate, so we shouldn't attribute this to the provider in the error.
If a resource is forced CreateBeforeDestroy from a dependent resource, and that dependent has no changes, the plan is changed from CreateThenDelete to DeleteThenCreate causing an apply error.
When applying a plan, a forced CreateBeforeDestroy may not be set during the apply walk when downstream resources are no longer present in the graph. We still need to stick to that plan, and both the NodeApplyableResourceInstance EvalTree and the individual Eval nodes need to operate on that planned value. Ensure that we always check for an existing plan when determining CreateBeforeDestroy status. This must happen in 2 different code paths due to the eval node pattern currently in-use. Future refactoring may be able to unify these code-paths to make this less fragile.
Codecov Report
|
mildwonkey
approved these changes
Sep 10, 2020
Merged
alanraison
added a commit
to alanraison/gitpod
that referenced
this pull request
Oct 2, 2020
In order to take advantage of hashicorp/terraform#26192, update to the latest terraform version.
csweichel
pushed a commit
to gitpod-io/gitpod
that referenced
this pull request
Oct 12, 2020
In order to take advantage of hashicorp/terraform#26192, update to the latest terraform version.
|
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further. |
ghost
locked as resolved and limited conversation to collaborators
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.
If the planed action changes from CreateThenDelete to DeleteThenCreate,
terraform will present an error like:
This was being reported to providers as the message indicated, so wasn't
immediately visible to core developers, e.g.
hashicorp/terraform-provider-aws#15044
hashicorp/terraform-provider-aws#15048
https://discuss.hashicorp.com/t/this-is-a-bug-in-the-provider-which-should-be-reported-in-the-providers-own-issue-tracker/13190
hashicorp/terraform-provider-aws#13823 (comment)
hashicorp/terraform-provider-aws#10297 (comment)
Since the provider does not influence the status of
CreateBeforeDestroy,we first fix the output to indicate that this is a bug in terraform.
In order to prevent the error, we need to check for a saved plan with a
CreateThenDeleteaction and rely on that to determine the status ofCreateBeforeDestroy. Due to the eval-node pattern currently in use,this needs to be maintained in both the apply node and the eval nodes.
Future refactoring can work on unifying these codepaths, and making
these internal flags less fragile.
Fixes #26180