IntenseWebs/opentofu
3
0
Fork 0
mirror of https://github.com/opentofu/opentofu.git synced 2024-12-30 10:47:14 -06:00
Code Issues Packages Projects Releases Wiki Activity
bc87be384b
opentofu/terraform/graph_builder_apply_test.go

836 lines
22 KiB
Go
Raw Normal View History

terraform: start apply-based graph builder, basic diff transform
2016-09-13 12:56:37 -05:00
package terraform
import (
core: Be more explicit in how we handle create_before_destroy Previously our handling of create_before_destroy -- and of deposed objects in particular -- was rather "implicit" and spread over various different subsystems. We'd quietly just destroy every deposed object during a destroy operation, without any user-visible plan to do so. Here we make things more explicit by tracking each deposed object individually by its pseudorandomly-allocated key. There are two different mechanisms at play here, building on the same concepts: - During a replace operation with create_before_destroy, we *pre-allocate* a DeposedKey to use for the prior object in the "apply" node and then pass that exact id to the destroy node, ensuring that we only destroy the single object we planned to destroy. In the happy path here the user never actually sees the allocated deposed key because we use it and then immediately destroy it within the same operation. However, that destroy may fail, which brings us to the second mechanism: - If any deposed objects are already present in state during _plan_, we insert a destroy change for them into the plan so that it's explicit to the user that we are going to destroy these additional objects, and then create an individual graph node for each one in DiffTransformer. The main motivation here is to be more careful in how we handle these destroys so that from a user's standpoint we never destroy something without the user knowing about it ahead of time. However, this new organization also hopefully makes the code itself a little easier to follow because the connection between the create and destroy steps of a Replace is reprseented in a single place (in DiffTransformer) and deposed instances each have their own explicit graph node rather than being secretly handled as part of the main instance-level graph node.
2018-09-20 14:30:52 -05:00
"fmt"
terraform: start apply-based graph builder, basic diff transform
2016-09-13 12:56:37 -05:00
"strings"
"testing"
core: Get tests compiling again After the refactoring to integrate HCL2 many of the tests were no longer using correct types, attribute names, etc. This is a bulk update of all of the tests to make them compile again, with minimal changes otherwise. Although the tests now compile, many of them do not yet pass. The tests will be gradually repaired in subsequent commits, as we continue to complete the refactoring and retrofit work.
2018-05-04 21:24:06 -05:00
"github.com/hashicorp/terraform/addrs"
core: Be more explicit in how we handle create_before_destroy Previously our handling of create_before_destroy -- and of deposed objects in particular -- was rather "implicit" and spread over various different subsystems. We'd quietly just destroy every deposed object during a destroy operation, without any user-visible plan to do so. Here we make things more explicit by tracking each deposed object individually by its pseudorandomly-allocated key. There are two different mechanisms at play here, building on the same concepts: - During a replace operation with create_before_destroy, we *pre-allocate* a DeposedKey to use for the prior object in the "apply" node and then pass that exact id to the destroy node, ensuring that we only destroy the single object we planned to destroy. In the happy path here the user never actually sees the allocated deposed key because we use it and then immediately destroy it within the same operation. However, that destroy may fail, which brings us to the second mechanism: - If any deposed objects are already present in state during _plan_, we insert a destroy change for them into the plan so that it's explicit to the user that we are going to destroy these additional objects, and then create an individual graph node for each one in DiffTransformer. The main motivation here is to be more careful in how we handle these destroys so that from a user's standpoint we never destroy something without the user knowing about it ahead of time. However, this new organization also hopefully makes the code itself a little easier to follow because the connection between the create and destroy steps of a Replace is reprseented in a single place (in DiffTransformer) and deposed instances each have their own explicit graph node rather than being secretly handled as part of the main instance-level graph node.
2018-09-20 14:30:52 -05:00
"github.com/hashicorp/terraform/plans"
"github.com/hashicorp/terraform/states"
failing test for update from orphaned instance Updates resulting from orphaned instances should happen after the deletion of the instances.
2019-10-29 09:57:38 -05:00
"github.com/zclconf/go-cty/cty"
terraform: start apply-based graph builder, basic diff transform
2016-09-13 12:56:37 -05:00
)
func TestApplyGraphBuilder_impl(t *testing.T) {
var _ GraphBuilder = new(ApplyGraphBuilder)
}
func TestApplyGraphBuilder(t *testing.T) {
terraform: Ugly huge change to weave in new State and Plan types Due to how often the state and plan types are referenced throughout Terraform, there isn't a great way to switch them out gradually. As a consequence, this huge commit gets us from the old world to a _compilable_ new world, but still has a large number of known test failures due to key functionality being stubbed out. The stubs here are for anything that interacts with providers, since we now need to do the follow-up work to similarly replace the old terraform.ResourceProvider interface with its replacement in the new "providers" package. That work, along with work to fix the remaining failing tests, will follow in subsequent commits. The aim here was to replace all references to terraform.State and its downstream types with states.State, terraform.Plan with plans.Plan, state.State with statemgr.State, and switch to the new implementations of the state and plan file formats. However, due to the number of times those types are used, this also ended up affecting numerous other parts of core such as terraform.Hook, the backend.Backend interface, and most of the CLI commands. Just as with 5861dbf3fc49b19587a31816eb06f511ab861bb4 before, I apologize in advance to the person who inevitably just found this huge commit while spelunking through the commit history.
2018-08-14 16:24:45 -05:00
changes := &plans.Changes{
Resources: []*plans.ResourceInstanceChangeSrc{
{
Addr: mustResourceInstanceAddr("test_object.create"),
ChangeSrc: plans.ChangeSrc{
Action: plans.Create,
terraform: start apply-based graph builder, basic diff transform
2016-09-13 12:56:37 -05:00
},
},
terraform: Ugly huge change to weave in new State and Plan types Due to how often the state and plan types are referenced throughout Terraform, there isn't a great way to switch them out gradually. As a consequence, this huge commit gets us from the old world to a _compilable_ new world, but still has a large number of known test failures due to key functionality being stubbed out. The stubs here are for anything that interacts with providers, since we now need to do the follow-up work to similarly replace the old terraform.ResourceProvider interface with its replacement in the new "providers" package. That work, along with work to fix the remaining failing tests, will follow in subsequent commits. The aim here was to replace all references to terraform.State and its downstream types with states.State, terraform.Plan with plans.Plan, state.State with statemgr.State, and switch to the new implementations of the state and plan file formats. However, due to the number of times those types are used, this also ended up affecting numerous other parts of core such as terraform.Hook, the backend.Backend interface, and most of the CLI commands. Just as with 5861dbf3fc49b19587a31816eb06f511ab861bb4 before, I apologize in advance to the person who inevitably just found this huge commit while spelunking through the commit history.
2018-08-14 16:24:45 -05:00
{
Addr: mustResourceInstanceAddr("test_object.other"),
ChangeSrc: plans.ChangeSrc{
Action: plans.Update,
},
},
{
Addr: mustResourceInstanceAddr("module.child.test_object.create"),
ChangeSrc: plans.ChangeSrc{
Action: plans.Create,
},
},
{
Addr: mustResourceInstanceAddr("module.child.test_object.other"),
ChangeSrc: plans.ChangeSrc{
Action: plans.Create,
terraform: ParentProviderTransform to connect parent providers
2016-09-14 16:43:14 -05:00
},
},
terraform: start apply-based graph builder, basic diff transform
2016-09-13 12:56:37 -05:00
},
}
b := &ApplyGraphBuilder{
update some graph builder tests Reduce the graphs, as they are too ungainly to compare without reduction. We also depend on reduction in all use cases, so we should be testing the graph as we use it anyway.
2018-09-24 18:25:40 -05:00
Config: testModule(t, "graph-builder-apply-basic"),
Changes: changes,
Components: simpleMockComponentFactory(),
Schemas: simpleTestSchemas(),
terraform: start apply-based graph builder, basic diff transform
2016-09-13 12:56:37 -05:00
}
core: Get tests compiling again After the refactoring to integrate HCL2 many of the tests were no longer using correct types, attribute names, etc. This is a bulk update of all of the tests to make them compile again, with minimal changes otherwise. Although the tests now compile, many of them do not yet pass. The tests will be gradually repaired in subsequent commits, as we continue to complete the refactoring and retrofit work.
2018-05-04 21:24:06 -05:00
g, err := b.Build(addrs.RootModuleInstance)
terraform: start apply-based graph builder, basic diff transform
2016-09-13 12:56:37 -05:00
if err != nil {
t.Fatalf("err: %s", err)
}
core: Get tests compiling again After the refactoring to integrate HCL2 many of the tests were no longer using correct types, attribute names, etc. This is a bulk update of all of the tests to make them compile again, with minimal changes otherwise. Although the tests now compile, many of them do not yet pass. The tests will be gradually repaired in subsequent commits, as we continue to complete the refactoring and retrofit work.
2018-05-04 21:24:06 -05:00
if g.Path.String() != addrs.RootModuleInstance.String() {
t.Fatalf("wrong path %q", g.Path.String())
terraform: start apply-based graph builder, basic diff transform
2016-09-13 12:56:37 -05:00
}
actual := strings.TrimSpace(g.String())
update some graph builder tests Reduce the graphs, as they are too ungainly to compare without reduction. We also depend on reduction in all use cases, so we should be testing the graph as we use it anyway.
2018-09-24 18:25:40 -05:00
terraform: start apply-based graph builder, basic diff transform
2016-09-13 12:56:37 -05:00
expected := strings.TrimSpace(testApplyGraphBuilderStr)
if actual != expected {
core: ApplyGraphBuilder tests to use the "test" mock provider These tests now need schema available to run properly, so rather than crafting a separate schema for each of these we'll just use the one created by simpleMockProvider, which contains a resource type called test_object that we'll now use as the basis for all of the tests here.
2018-05-10 17:38:58 -05:00
t.Fatalf("wrong result\n\ngot:\n%s\n\nwant:\n%s", actual, expected)
terraform: start apply-based graph builder, basic diff transform
2016-09-13 12:56:37 -05:00
}
}
terraform: CBD destroy nodes should not advertise themselves as normal
2017-02-07 13:49:50 -06:00
// This tests the ordering of two resources where a non-CBD depends
// on a CBD. GH-11349.
func TestApplyGraphBuilder_depCbd(t *testing.T) {
terraform: Ugly huge change to weave in new State and Plan types Due to how often the state and plan types are referenced throughout Terraform, there isn't a great way to switch them out gradually. As a consequence, this huge commit gets us from the old world to a _compilable_ new world, but still has a large number of known test failures due to key functionality being stubbed out. The stubs here are for anything that interacts with providers, since we now need to do the follow-up work to similarly replace the old terraform.ResourceProvider interface with its replacement in the new "providers" package. That work, along with work to fix the remaining failing tests, will follow in subsequent commits. The aim here was to replace all references to terraform.State and its downstream types with states.State, terraform.Plan with plans.Plan, state.State with statemgr.State, and switch to the new implementations of the state and plan file formats. However, due to the number of times those types are used, this also ended up affecting numerous other parts of core such as terraform.Hook, the backend.Backend interface, and most of the CLI commands. Just as with 5861dbf3fc49b19587a31816eb06f511ab861bb4 before, I apologize in advance to the person who inevitably just found this huge commit while spelunking through the commit history.
2018-08-14 16:24:45 -05:00
changes := &plans.Changes{
Resources: []*plans.ResourceInstanceChangeSrc{
{
Addr: mustResourceInstanceAddr("test_object.A"),
ChangeSrc: plans.ChangeSrc{
core: Handle forced-create_before_destroy during the plan walk Previously we used a single plan action "Replace" to represent both the destroy-before-create and the create-before-destroy variants of replacing. However, this forces the apply graph builder to jump through a lot of hoops to figure out which nodes need it forced on and rebuild parts of the graph to represent that. If we instead decide between these two cases at plan time, the actual determination of it is more straightforward because each resource is represented by only one node in the plan graph, and then we can ensure we put the right nodes in the graph during DiffTransformer and thus avoid the logic for dealing with deposed instances being spread across various different transformers and node types. As a nice side-effect, this also allows us to show the difference between destroy-then-create and create-then-destroy in the rendered diff in the CLI, although this change doesn't fully implement that yet.
2018-09-21 19:08:52 -05:00
Action: plans.CreateThenDelete,
terraform: outputs should not be included if not targeted Fixes #10911 Outputs that aren't targeted shouldn't be included in the graph. This requires passing targets to the apply graph. This is unfortunate but long term should be removable since I'd like to move output changes to the diff as well.
2017-02-13 14:52:45 -06:00
},
terraform: Ugly huge change to weave in new State and Plan types Due to how often the state and plan types are referenced throughout Terraform, there isn't a great way to switch them out gradually. As a consequence, this huge commit gets us from the old world to a _compilable_ new world, but still has a large number of known test failures due to key functionality being stubbed out. The stubs here are for anything that interacts with providers, since we now need to do the follow-up work to similarly replace the old terraform.ResourceProvider interface with its replacement in the new "providers" package. That work, along with work to fix the remaining failing tests, will follow in subsequent commits. The aim here was to replace all references to terraform.State and its downstream types with states.State, terraform.Plan with plans.Plan, state.State with statemgr.State, and switch to the new implementations of the state and plan file formats. However, due to the number of times those types are used, this also ended up affecting numerous other parts of core such as terraform.Hook, the backend.Backend interface, and most of the CLI commands. Just as with 5861dbf3fc49b19587a31816eb06f511ab861bb4 before, I apologize in advance to the person who inevitably just found this huge commit while spelunking through the commit history.
2018-08-14 16:24:45 -05:00
},
{
Addr: mustResourceInstanceAddr("test_object.B"),
ChangeSrc: plans.ChangeSrc{
Action: plans.Update,
terraform: CBD destroy nodes should not advertise themselves as normal
2017-02-07 13:49:50 -06:00
},
},
},
}
update test states that need dependency info A number of tests had no, or incomplete state for the transformations they wanted to test. Add states state with the correct dependencies for these tests.
2019-11-19 16:41:45 -06:00
state := states.NewState()
root := state.EnsureModule(addrs.RootModuleInstance)
root.SetResourceInstanceCurrent(
mustResourceInstanceAddr("test_object.A").Resource,
&states.ResourceInstanceObjectSrc{
Status: states.ObjectReady,
AttrsJSON: []byte(`{"id":"A"}`),
},
Mildwonkey/tests (#24522) * terraform: add helper functions for creating test state testSetResourceInstanceCurrent and testSetResourceInstanceTainted are wrapper functions around states.Module.SetResourceInstanceCurrent() used to set a resource in state. They work with current, non-deposed resources with no dependencies. testSetResourceInstanceDeposed can be used to set a desosed resource in state. * terraform: update all tests to use modern providers and state
2020-04-01 12:13:40 -05:00
mustProviderConfig(`provider["registry.terraform.io/hashicorp/test"]`),
update test states that need dependency info A number of tests had no, or incomplete state for the transformations they wanted to test. Add states state with the correct dependencies for these tests.
2019-11-19 16:41:45 -06:00
)
root.SetResourceInstanceCurrent(
mustResourceInstanceAddr("test_object.B").Resource,
&states.ResourceInstanceObjectSrc{
Status: states.ObjectReady,
AttrsJSON: []byte(`{"id":"B","test_list":["x"]}`),
terraform: rename mustReourceAddr to mustConfigResourceAddr and add mustAbsResourceAddr there are too many things that can be called resource addrs and it can be hard to find the must* I'm looking for, so I renamed one and added another.
2020-09-24 10:57:43 -05:00
Dependencies: []addrs.ConfigResource{mustConfigResourceAddr("test_object.A")},
update test states that need dependency info A number of tests had no, or incomplete state for the transformations they wanted to test. Add states state with the correct dependencies for these tests.
2019-11-19 16:41:45 -06:00
},
Mildwonkey/tests (#24522) * terraform: add helper functions for creating test state testSetResourceInstanceCurrent and testSetResourceInstanceTainted are wrapper functions around states.Module.SetResourceInstanceCurrent() used to set a resource in state. They work with current, non-deposed resources with no dependencies. testSetResourceInstanceDeposed can be used to set a desosed resource in state. * terraform: update all tests to use modern providers and state
2020-04-01 12:13:40 -05:00
mustProviderConfig(`provider["registry.terraform.io/hashicorp/test"]`),
update test states that need dependency info A number of tests had no, or incomplete state for the transformations they wanted to test. Add states state with the correct dependencies for these tests.
2019-11-19 16:41:45 -06:00
)
terraform: CBD destroy nodes should not advertise themselves as normal
2017-02-07 13:49:50 -06:00
b := &ApplyGraphBuilder{
update some graph builder tests Reduce the graphs, as they are too ungainly to compare without reduction. We also depend on reduction in all use cases, so we should be testing the graph as we use it anyway.
2018-09-24 18:25:40 -05:00
Config: testModule(t, "graph-builder-apply-dep-cbd"),
Changes: changes,
Components: simpleMockComponentFactory(),
Schemas: simpleTestSchemas(),
update test states that need dependency info A number of tests had no, or incomplete state for the transformations they wanted to test. Add states state with the correct dependencies for these tests.
2019-11-19 16:41:45 -06:00
State: state,
terraform: CBD destroy nodes should not advertise themselves as normal
2017-02-07 13:49:50 -06:00
}
core: Get tests compiling again After the refactoring to integrate HCL2 many of the tests were no longer using correct types, attribute names, etc. This is a bulk update of all of the tests to make them compile again, with minimal changes otherwise. Although the tests now compile, many of them do not yet pass. The tests will be gradually repaired in subsequent commits, as we continue to complete the refactoring and retrofit work.
2018-05-04 21:24:06 -05:00
g, err := b.Build(addrs.RootModuleInstance)
terraform: CBD destroy nodes should not advertise themselves as normal
2017-02-07 13:49:50 -06:00
if err != nil {
t.Fatalf("err: %s", err)
}
core: Get tests compiling again After the refactoring to integrate HCL2 many of the tests were no longer using correct types, attribute names, etc. This is a bulk update of all of the tests to make them compile again, with minimal changes otherwise. Although the tests now compile, many of them do not yet pass. The tests will be gradually repaired in subsequent commits, as we continue to complete the refactoring and retrofit work.
2018-05-04 21:24:06 -05:00
if g.Path.String() != addrs.RootModuleInstance.String() {
t.Fatalf("wrong path %q", g.Path.String())
terraform: CBD destroy nodes should not advertise themselves as normal
2017-02-07 13:49:50 -06:00
}
core: Be more explicit in how we handle create_before_destroy Previously our handling of create_before_destroy -- and of deposed objects in particular -- was rather "implicit" and spread over various different subsystems. We'd quietly just destroy every deposed object during a destroy operation, without any user-visible plan to do so. Here we make things more explicit by tracking each deposed object individually by its pseudorandomly-allocated key. There are two different mechanisms at play here, building on the same concepts: - During a replace operation with create_before_destroy, we *pre-allocate* a DeposedKey to use for the prior object in the "apply" node and then pass that exact id to the destroy node, ensuring that we only destroy the single object we planned to destroy. In the happy path here the user never actually sees the allocated deposed key because we use it and then immediately destroy it within the same operation. However, that destroy may fail, which brings us to the second mechanism: - If any deposed objects are already present in state during _plan_, we insert a destroy change for them into the plan so that it's explicit to the user that we are going to destroy these additional objects, and then create an individual graph node for each one in DiffTransformer. The main motivation here is to be more careful in how we handle these destroys so that from a user's standpoint we never destroy something without the user knowing about it ahead of time. However, this new organization also hopefully makes the code itself a little easier to follow because the connection between the create and destroy steps of a Replace is reprseented in a single place (in DiffTransformer) and deposed instances each have their own explicit graph node rather than being secretly handled as part of the main instance-level graph node.
2018-09-20 14:30:52 -05:00
// We're going to go hunting for our deposed instance node here, so we
// can find out its key to use in the assertions below.
var dk states.DeposedKey
for _, v := range g.Vertices() {
tv, ok := v.(*NodeDestroyDeposedResourceInstanceObject)
if !ok {
continue
}
if dk != states.NotDeposed {
t.Fatalf("more than one deposed instance node in the graph; want only one")
}
dk = tv.DeposedKey
}
if dk == states.NotDeposed {
t.Fatalf("no deposed instance node in the graph; want one")
}
update some graph builder tests Reduce the graphs, as they are too ungainly to compare without reduction. We also depend on reduction in all use cases, so we should be testing the graph as we use it anyway.
2018-09-24 18:25:40 -05:00
destroyName := fmt.Sprintf("test_object.A (destroy deposed %s)", dk)
core: Be more explicit in how we handle create_before_destroy Previously our handling of create_before_destroy -- and of deposed objects in particular -- was rather "implicit" and spread over various different subsystems. We'd quietly just destroy every deposed object during a destroy operation, without any user-visible plan to do so. Here we make things more explicit by tracking each deposed object individually by its pseudorandomly-allocated key. There are two different mechanisms at play here, building on the same concepts: - During a replace operation with create_before_destroy, we *pre-allocate* a DeposedKey to use for the prior object in the "apply" node and then pass that exact id to the destroy node, ensuring that we only destroy the single object we planned to destroy. In the happy path here the user never actually sees the allocated deposed key because we use it and then immediately destroy it within the same operation. However, that destroy may fail, which brings us to the second mechanism: - If any deposed objects are already present in state during _plan_, we insert a destroy change for them into the plan so that it's explicit to the user that we are going to destroy these additional objects, and then create an individual graph node for each one in DiffTransformer. The main motivation here is to be more careful in how we handle these destroys so that from a user's standpoint we never destroy something without the user knowing about it ahead of time. However, this new organization also hopefully makes the code itself a little easier to follow because the connection between the create and destroy steps of a Replace is reprseented in a single place (in DiffTransformer) and deposed instances each have their own explicit graph node rather than being secretly handled as part of the main instance-level graph node.
2018-09-20 14:30:52 -05:00
terraform: CBD destroy nodes should not advertise themselves as normal
2017-02-07 13:49:50 -06:00
// Create A, Modify B, Destroy A
testGraphHappensBefore(
t, g,
core: ApplyGraphBuilder tests to use the "test" mock provider These tests now need schema available to run properly, so rather than crafting a separate schema for each of these we'll just use the one created by simpleMockProvider, which contains a resource type called test_object that we'll now use as the basis for all of the tests here.
2018-05-10 17:38:58 -05:00
"test_object.A",
core: Be more explicit in how we handle create_before_destroy Previously our handling of create_before_destroy -- and of deposed objects in particular -- was rather "implicit" and spread over various different subsystems. We'd quietly just destroy every deposed object during a destroy operation, without any user-visible plan to do so. Here we make things more explicit by tracking each deposed object individually by its pseudorandomly-allocated key. There are two different mechanisms at play here, building on the same concepts: - During a replace operation with create_before_destroy, we *pre-allocate* a DeposedKey to use for the prior object in the "apply" node and then pass that exact id to the destroy node, ensuring that we only destroy the single object we planned to destroy. In the happy path here the user never actually sees the allocated deposed key because we use it and then immediately destroy it within the same operation. However, that destroy may fail, which brings us to the second mechanism: - If any deposed objects are already present in state during _plan_, we insert a destroy change for them into the plan so that it's explicit to the user that we are going to destroy these additional objects, and then create an individual graph node for each one in DiffTransformer. The main motivation here is to be more careful in how we handle these destroys so that from a user's standpoint we never destroy something without the user knowing about it ahead of time. However, this new organization also hopefully makes the code itself a little easier to follow because the connection between the create and destroy steps of a Replace is reprseented in a single place (in DiffTransformer) and deposed instances each have their own explicit graph node rather than being secretly handled as part of the main instance-level graph node.
2018-09-20 14:30:52 -05:00
destroyName,
)
terraform: add one more forgotten ordering assertion
2017-02-07 14:01:27 -06:00
testGraphHappensBefore(
t, g,
core: ApplyGraphBuilder tests to use the "test" mock provider These tests now need schema available to run properly, so rather than crafting a separate schema for each of these we'll just use the one created by simpleMockProvider, which contains a resource type called test_object that we'll now use as the basis for all of the tests here.
2018-05-10 17:38:58 -05:00
"test_object.A",
core: Be more explicit in how we handle create_before_destroy Previously our handling of create_before_destroy -- and of deposed objects in particular -- was rather "implicit" and spread over various different subsystems. We'd quietly just destroy every deposed object during a destroy operation, without any user-visible plan to do so. Here we make things more explicit by tracking each deposed object individually by its pseudorandomly-allocated key. There are two different mechanisms at play here, building on the same concepts: - During a replace operation with create_before_destroy, we *pre-allocate* a DeposedKey to use for the prior object in the "apply" node and then pass that exact id to the destroy node, ensuring that we only destroy the single object we planned to destroy. In the happy path here the user never actually sees the allocated deposed key because we use it and then immediately destroy it within the same operation. However, that destroy may fail, which brings us to the second mechanism: - If any deposed objects are already present in state during _plan_, we insert a destroy change for them into the plan so that it's explicit to the user that we are going to destroy these additional objects, and then create an individual graph node for each one in DiffTransformer. The main motivation here is to be more careful in how we handle these destroys so that from a user's standpoint we never destroy something without the user knowing about it ahead of time. However, this new organization also hopefully makes the code itself a little easier to follow because the connection between the create and destroy steps of a Replace is reprseented in a single place (in DiffTransformer) and deposed instances each have their own explicit graph node rather than being secretly handled as part of the main instance-level graph node.
2018-09-20 14:30:52 -05:00
"test_object.B",
)
terraform: CBD destroy nodes should not advertise themselves as normal
2017-02-07 13:49:50 -06:00
testGraphHappensBefore(
t, g,
core: ApplyGraphBuilder tests to use the "test" mock provider These tests now need schema available to run properly, so rather than crafting a separate schema for each of these we'll just use the one created by simpleMockProvider, which contains a resource type called test_object that we'll now use as the basis for all of the tests here.
2018-05-10 17:38:58 -05:00
"test_object.B",
core: Be more explicit in how we handle create_before_destroy Previously our handling of create_before_destroy -- and of deposed objects in particular -- was rather "implicit" and spread over various different subsystems. We'd quietly just destroy every deposed object during a destroy operation, without any user-visible plan to do so. Here we make things more explicit by tracking each deposed object individually by its pseudorandomly-allocated key. There are two different mechanisms at play here, building on the same concepts: - During a replace operation with create_before_destroy, we *pre-allocate* a DeposedKey to use for the prior object in the "apply" node and then pass that exact id to the destroy node, ensuring that we only destroy the single object we planned to destroy. In the happy path here the user never actually sees the allocated deposed key because we use it and then immediately destroy it within the same operation. However, that destroy may fail, which brings us to the second mechanism: - If any deposed objects are already present in state during _plan_, we insert a destroy change for them into the plan so that it's explicit to the user that we are going to destroy these additional objects, and then create an individual graph node for each one in DiffTransformer. The main motivation here is to be more careful in how we handle these destroys so that from a user's standpoint we never destroy something without the user knowing about it ahead of time. However, this new organization also hopefully makes the code itself a little easier to follow because the connection between the create and destroy steps of a Replace is reprseented in a single place (in DiffTransformer) and deposed instances each have their own explicit graph node rather than being secretly handled as part of the main instance-level graph node.
2018-09-20 14:30:52 -05:00
destroyName,
)
terraform: CBD destroy nodes should not advertise themselves as normal
2017-02-07 13:49:50 -06:00
}
terraform: apply resource must depend on destroy deps Fixes #10440 This updates the behavior of "apply" resources to depend on the destroy versions of their dependencies. We make an exception to this behavior when the "apply" resource is CBD. This is odd and not 100% correct, but it mimics the behavior of the legacy graphs and avoids us having to do major core work to support the 100% correct solution. I'll explain this in examples... Given the following configuration: resource "null_resource" "a" { count = "${var.count}" } resource "null_resource" "b" { triggers { key = "${join(",", null_resource.a.*.id)}" } } Assume we've successfully created this configuration with count = 2. When going from count = 2 to count = 1, `null_resource.b` should wait for `null_resource.a.1` to destroy. If it doesn't, then it is a race: depending when we interpolate the `triggers.key` attribute of `null_resource.b`, we may get 1 value or 2. If `null_resource.a.1` is destroyed, we'll get 1. Otherwise, we'll get 2. This was the root cause of #10440 In the legacy graphs, `null_resource.b` would depend on the destruction of any `null_resource.a` (orphans, tainted, anything!). This would ensure proper ordering. We mimic that behavior here. The difference is CBD. If `null_resource.b` has CBD enabled, then the ordering **in the legacy graph** becomes: 1. null_resource.b (create) 2. null_resource.b (destroy) 3. null_resource.a (destroy) In this case, the update would always have 2 values for `triggers.key`, even though we were destroying a resource later! This scenario required two `terraform apply` operations. This is what the CBD check is for in this PR. We do this to mimic the behavior of the legacy graph. The correct solution to do one day is to allow splat references (`null_resource.a.*.id`) to happen in parallel and only read up to to the `count` amount in the state. This requires some fairly significant work close to the 0.8 release date, so we can defer this to later and adopt the 0.7.x behavior for now.
2016-12-04 01:44:09 -06:00
// This tests the ordering of two resources that are both CBD that
// require destroy/create.
func TestApplyGraphBuilder_doubleCBD(t *testing.T) {
terraform: Ugly huge change to weave in new State and Plan types Due to how often the state and plan types are referenced throughout Terraform, there isn't a great way to switch them out gradually. As a consequence, this huge commit gets us from the old world to a _compilable_ new world, but still has a large number of known test failures due to key functionality being stubbed out. The stubs here are for anything that interacts with providers, since we now need to do the follow-up work to similarly replace the old terraform.ResourceProvider interface with its replacement in the new "providers" package. That work, along with work to fix the remaining failing tests, will follow in subsequent commits. The aim here was to replace all references to terraform.State and its downstream types with states.State, terraform.Plan with plans.Plan, state.State with statemgr.State, and switch to the new implementations of the state and plan file formats. However, due to the number of times those types are used, this also ended up affecting numerous other parts of core such as terraform.Hook, the backend.Backend interface, and most of the CLI commands. Just as with 5861dbf3fc49b19587a31816eb06f511ab861bb4 before, I apologize in advance to the person who inevitably just found this huge commit while spelunking through the commit history.
2018-08-14 16:24:45 -05:00
changes := &plans.Changes{
Resources: []*plans.ResourceInstanceChangeSrc{
{
Addr: mustResourceInstanceAddr("test_object.A"),
ChangeSrc: plans.ChangeSrc{
core: Handle forced-create_before_destroy during the plan walk Previously we used a single plan action "Replace" to represent both the destroy-before-create and the create-before-destroy variants of replacing. However, this forces the apply graph builder to jump through a lot of hoops to figure out which nodes need it forced on and rebuild parts of the graph to represent that. If we instead decide between these two cases at plan time, the actual determination of it is more straightforward because each resource is represented by only one node in the plan graph, and then we can ensure we put the right nodes in the graph during DiffTransformer and thus avoid the logic for dealing with deposed instances being spread across various different transformers and node types. As a nice side-effect, this also allows us to show the difference between destroy-then-create and create-then-destroy in the rendered diff in the CLI, although this change doesn't fully implement that yet.
2018-09-21 19:08:52 -05:00
Action: plans.CreateThenDelete,
terraform: Ugly huge change to weave in new State and Plan types Due to how often the state and plan types are referenced throughout Terraform, there isn't a great way to switch them out gradually. As a consequence, this huge commit gets us from the old world to a _compilable_ new world, but still has a large number of known test failures due to key functionality being stubbed out. The stubs here are for anything that interacts with providers, since we now need to do the follow-up work to similarly replace the old terraform.ResourceProvider interface with its replacement in the new "providers" package. That work, along with work to fix the remaining failing tests, will follow in subsequent commits. The aim here was to replace all references to terraform.State and its downstream types with states.State, terraform.Plan with plans.Plan, state.State with statemgr.State, and switch to the new implementations of the state and plan file formats. However, due to the number of times those types are used, this also ended up affecting numerous other parts of core such as terraform.Hook, the backend.Backend interface, and most of the CLI commands. Just as with 5861dbf3fc49b19587a31816eb06f511ab861bb4 before, I apologize in advance to the person who inevitably just found this huge commit while spelunking through the commit history.
2018-08-14 16:24:45 -05:00
},
},
{
Addr: mustResourceInstanceAddr("test_object.B"),
ChangeSrc: plans.ChangeSrc{
core: Handle forced-create_before_destroy during the plan walk Previously we used a single plan action "Replace" to represent both the destroy-before-create and the create-before-destroy variants of replacing. However, this forces the apply graph builder to jump through a lot of hoops to figure out which nodes need it forced on and rebuild parts of the graph to represent that. If we instead decide between these two cases at plan time, the actual determination of it is more straightforward because each resource is represented by only one node in the plan graph, and then we can ensure we put the right nodes in the graph during DiffTransformer and thus avoid the logic for dealing with deposed instances being spread across various different transformers and node types. As a nice side-effect, this also allows us to show the difference between destroy-then-create and create-then-destroy in the rendered diff in the CLI, although this change doesn't fully implement that yet.
2018-09-21 19:08:52 -05:00
Action: plans.CreateThenDelete,
terraform: apply resource must depend on destroy deps Fixes #10440 This updates the behavior of "apply" resources to depend on the destroy versions of their dependencies. We make an exception to this behavior when the "apply" resource is CBD. This is odd and not 100% correct, but it mimics the behavior of the legacy graphs and avoids us having to do major core work to support the 100% correct solution. I'll explain this in examples... Given the following configuration: resource "null_resource" "a" { count = "${var.count}" } resource "null_resource" "b" { triggers { key = "${join(",", null_resource.a.*.id)}" } } Assume we've successfully created this configuration with count = 2. When going from count = 2 to count = 1, `null_resource.b` should wait for `null_resource.a.1` to destroy. If it doesn't, then it is a race: depending when we interpolate the `triggers.key` attribute of `null_resource.b`, we may get 1 value or 2. If `null_resource.a.1` is destroyed, we'll get 1. Otherwise, we'll get 2. This was the root cause of #10440 In the legacy graphs, `null_resource.b` would depend on the destruction of any `null_resource.a` (orphans, tainted, anything!). This would ensure proper ordering. We mimic that behavior here. The difference is CBD. If `null_resource.b` has CBD enabled, then the ordering **in the legacy graph** becomes: 1. null_resource.b (create) 2. null_resource.b (destroy) 3. null_resource.a (destroy) In this case, the update would always have 2 values for `triggers.key`, even though we were destroying a resource later! This scenario required two `terraform apply` operations. This is what the CBD check is for in this PR. We do this to mimic the behavior of the legacy graph. The correct solution to do one day is to allow splat references (`null_resource.a.*.id`) to happen in parallel and only read up to to the `count` amount in the state. This requires some fairly significant work close to the 0.8 release date, so we can defer this to later and adopt the 0.7.x behavior for now.
2016-12-04 01:44:09 -06:00
},
},
},
}
b := &ApplyGraphBuilder{
terraform: remove DisableReduce from refresh, plan and apply graphs (#25824)
2020-08-14 13:13:33 -05:00
Config: testModule(t, "graph-builder-apply-double-cbd"),
Changes: changes,
Components: simpleMockComponentFactory(),
Schemas: simpleTestSchemas(),
terraform: apply resource must depend on destroy deps Fixes #10440 This updates the behavior of "apply" resources to depend on the destroy versions of their dependencies. We make an exception to this behavior when the "apply" resource is CBD. This is odd and not 100% correct, but it mimics the behavior of the legacy graphs and avoids us having to do major core work to support the 100% correct solution. I'll explain this in examples... Given the following configuration: resource "null_resource" "a" { count = "${var.count}" } resource "null_resource" "b" { triggers { key = "${join(",", null_resource.a.*.id)}" } } Assume we've successfully created this configuration with count = 2. When going from count = 2 to count = 1, `null_resource.b` should wait for `null_resource.a.1` to destroy. If it doesn't, then it is a race: depending when we interpolate the `triggers.key` attribute of `null_resource.b`, we may get 1 value or 2. If `null_resource.a.1` is destroyed, we'll get 1. Otherwise, we'll get 2. This was the root cause of #10440 In the legacy graphs, `null_resource.b` would depend on the destruction of any `null_resource.a` (orphans, tainted, anything!). This would ensure proper ordering. We mimic that behavior here. The difference is CBD. If `null_resource.b` has CBD enabled, then the ordering **in the legacy graph** becomes: 1. null_resource.b (create) 2. null_resource.b (destroy) 3. null_resource.a (destroy) In this case, the update would always have 2 values for `triggers.key`, even though we were destroying a resource later! This scenario required two `terraform apply` operations. This is what the CBD check is for in this PR. We do this to mimic the behavior of the legacy graph. The correct solution to do one day is to allow splat references (`null_resource.a.*.id`) to happen in parallel and only read up to to the `count` amount in the state. This requires some fairly significant work close to the 0.8 release date, so we can defer this to later and adopt the 0.7.x behavior for now.
2016-12-04 01:44:09 -06:00
}
core: Get tests compiling again After the refactoring to integrate HCL2 many of the tests were no longer using correct types, attribute names, etc. This is a bulk update of all of the tests to make them compile again, with minimal changes otherwise. Although the tests now compile, many of them do not yet pass. The tests will be gradually repaired in subsequent commits, as we continue to complete the refactoring and retrofit work.
2018-05-04 21:24:06 -05:00
g, err := b.Build(addrs.RootModuleInstance)
terraform: apply resource must depend on destroy deps Fixes #10440 This updates the behavior of "apply" resources to depend on the destroy versions of their dependencies. We make an exception to this behavior when the "apply" resource is CBD. This is odd and not 100% correct, but it mimics the behavior of the legacy graphs and avoids us having to do major core work to support the 100% correct solution. I'll explain this in examples... Given the following configuration: resource "null_resource" "a" { count = "${var.count}" } resource "null_resource" "b" { triggers { key = "${join(",", null_resource.a.*.id)}" } } Assume we've successfully created this configuration with count = 2. When going from count = 2 to count = 1, `null_resource.b` should wait for `null_resource.a.1` to destroy. If it doesn't, then it is a race: depending when we interpolate the `triggers.key` attribute of `null_resource.b`, we may get 1 value or 2. If `null_resource.a.1` is destroyed, we'll get 1. Otherwise, we'll get 2. This was the root cause of #10440 In the legacy graphs, `null_resource.b` would depend on the destruction of any `null_resource.a` (orphans, tainted, anything!). This would ensure proper ordering. We mimic that behavior here. The difference is CBD. If `null_resource.b` has CBD enabled, then the ordering **in the legacy graph** becomes: 1. null_resource.b (create) 2. null_resource.b (destroy) 3. null_resource.a (destroy) In this case, the update would always have 2 values for `triggers.key`, even though we were destroying a resource later! This scenario required two `terraform apply` operations. This is what the CBD check is for in this PR. We do this to mimic the behavior of the legacy graph. The correct solution to do one day is to allow splat references (`null_resource.a.*.id`) to happen in parallel and only read up to to the `count` amount in the state. This requires some fairly significant work close to the 0.8 release date, so we can defer this to later and adopt the 0.7.x behavior for now.
2016-12-04 01:44:09 -06:00
if err != nil {
t.Fatalf("err: %s", err)
}
core: Get tests compiling again After the refactoring to integrate HCL2 many of the tests were no longer using correct types, attribute names, etc. This is a bulk update of all of the tests to make them compile again, with minimal changes otherwise. Although the tests now compile, many of them do not yet pass. The tests will be gradually repaired in subsequent commits, as we continue to complete the refactoring and retrofit work.
2018-05-04 21:24:06 -05:00
if g.Path.String() != addrs.RootModuleInstance.String() {
t.Fatalf("wrong path %q", g.Path.String())
terraform: apply resource must depend on destroy deps Fixes #10440 This updates the behavior of "apply" resources to depend on the destroy versions of their dependencies. We make an exception to this behavior when the "apply" resource is CBD. This is odd and not 100% correct, but it mimics the behavior of the legacy graphs and avoids us having to do major core work to support the 100% correct solution. I'll explain this in examples... Given the following configuration: resource "null_resource" "a" { count = "${var.count}" } resource "null_resource" "b" { triggers { key = "${join(",", null_resource.a.*.id)}" } } Assume we've successfully created this configuration with count = 2. When going from count = 2 to count = 1, `null_resource.b` should wait for `null_resource.a.1` to destroy. If it doesn't, then it is a race: depending when we interpolate the `triggers.key` attribute of `null_resource.b`, we may get 1 value or 2. If `null_resource.a.1` is destroyed, we'll get 1. Otherwise, we'll get 2. This was the root cause of #10440 In the legacy graphs, `null_resource.b` would depend on the destruction of any `null_resource.a` (orphans, tainted, anything!). This would ensure proper ordering. We mimic that behavior here. The difference is CBD. If `null_resource.b` has CBD enabled, then the ordering **in the legacy graph** becomes: 1. null_resource.b (create) 2. null_resource.b (destroy) 3. null_resource.a (destroy) In this case, the update would always have 2 values for `triggers.key`, even though we were destroying a resource later! This scenario required two `terraform apply` operations. This is what the CBD check is for in this PR. We do this to mimic the behavior of the legacy graph. The correct solution to do one day is to allow splat references (`null_resource.a.*.id`) to happen in parallel and only read up to to the `count` amount in the state. This requires some fairly significant work close to the 0.8 release date, so we can defer this to later and adopt the 0.7.x behavior for now.
2016-12-04 01:44:09 -06:00
}
finish graph builder test updates
2018-09-25 09:42:44 -05:00
// We're going to go hunting for our deposed instance node here, so we
// can find out its key to use in the assertions below.
var destroyA, destroyB string
for _, v := range g.Vertices() {
tv, ok := v.(*NodeDestroyDeposedResourceInstanceObject)
if !ok {
continue
}
Add Path to more nodes that require it.
2020-03-23 07:56:55 -05:00
switch tv.Addr.Resource.Resource.Name {
finish graph builder test updates
2018-09-25 09:42:44 -05:00
case "A":
destroyA = fmt.Sprintf("test_object.A (destroy deposed %s)", tv.DeposedKey)
case "B":
destroyB = fmt.Sprintf("test_object.B (destroy deposed %s)", tv.DeposedKey)
default:
t.Fatalf("unknown instance: %s", tv.Addr)
}
terraform: apply resource must depend on destroy deps Fixes #10440 This updates the behavior of "apply" resources to depend on the destroy versions of their dependencies. We make an exception to this behavior when the "apply" resource is CBD. This is odd and not 100% correct, but it mimics the behavior of the legacy graphs and avoids us having to do major core work to support the 100% correct solution. I'll explain this in examples... Given the following configuration: resource "null_resource" "a" { count = "${var.count}" } resource "null_resource" "b" { triggers { key = "${join(",", null_resource.a.*.id)}" } } Assume we've successfully created this configuration with count = 2. When going from count = 2 to count = 1, `null_resource.b` should wait for `null_resource.a.1` to destroy. If it doesn't, then it is a race: depending when we interpolate the `triggers.key` attribute of `null_resource.b`, we may get 1 value or 2. If `null_resource.a.1` is destroyed, we'll get 1. Otherwise, we'll get 2. This was the root cause of #10440 In the legacy graphs, `null_resource.b` would depend on the destruction of any `null_resource.a` (orphans, tainted, anything!). This would ensure proper ordering. We mimic that behavior here. The difference is CBD. If `null_resource.b` has CBD enabled, then the ordering **in the legacy graph** becomes: 1. null_resource.b (create) 2. null_resource.b (destroy) 3. null_resource.a (destroy) In this case, the update would always have 2 values for `triggers.key`, even though we were destroying a resource later! This scenario required two `terraform apply` operations. This is what the CBD check is for in this PR. We do this to mimic the behavior of the legacy graph. The correct solution to do one day is to allow splat references (`null_resource.a.*.id`) to happen in parallel and only read up to to the `count` amount in the state. This requires some fairly significant work close to the 0.8 release date, so we can defer this to later and adopt the 0.7.x behavior for now.
2016-12-04 01:44:09 -06:00
}
finish graph builder test updates
2018-09-25 09:42:44 -05:00
// Create A, Modify B, Destroy A
testGraphHappensBefore(
t, g,
"test_object.A",
destroyA,
)
testGraphHappensBefore(
t, g,
"test_object.A",
"test_object.B",
)
testGraphHappensBefore(
t, g,
"test_object.B",
destroyB,
)
terraform: apply resource must depend on destroy deps Fixes #10440 This updates the behavior of "apply" resources to depend on the destroy versions of their dependencies. We make an exception to this behavior when the "apply" resource is CBD. This is odd and not 100% correct, but it mimics the behavior of the legacy graphs and avoids us having to do major core work to support the 100% correct solution. I'll explain this in examples... Given the following configuration: resource "null_resource" "a" { count = "${var.count}" } resource "null_resource" "b" { triggers { key = "${join(",", null_resource.a.*.id)}" } } Assume we've successfully created this configuration with count = 2. When going from count = 2 to count = 1, `null_resource.b` should wait for `null_resource.a.1` to destroy. If it doesn't, then it is a race: depending when we interpolate the `triggers.key` attribute of `null_resource.b`, we may get 1 value or 2. If `null_resource.a.1` is destroyed, we'll get 1. Otherwise, we'll get 2. This was the root cause of #10440 In the legacy graphs, `null_resource.b` would depend on the destruction of any `null_resource.a` (orphans, tainted, anything!). This would ensure proper ordering. We mimic that behavior here. The difference is CBD. If `null_resource.b` has CBD enabled, then the ordering **in the legacy graph** becomes: 1. null_resource.b (create) 2. null_resource.b (destroy) 3. null_resource.a (destroy) In this case, the update would always have 2 values for `triggers.key`, even though we were destroying a resource later! This scenario required two `terraform apply` operations. This is what the CBD check is for in this PR. We do this to mimic the behavior of the legacy graph. The correct solution to do one day is to allow splat references (`null_resource.a.*.id`) to happen in parallel and only read up to to the `count` amount in the state. This requires some fairly significant work close to the 0.8 release date, so we can defer this to later and adopt the 0.7.x behavior for now.
2016-12-04 01:44:09 -06:00
}
terraform: node referenceable name from state shuldn't contain path Fixes #11749 I'm **really** surprised this didn't come up earlier. When only the state is available for a node, the advertised referenceable name (the name used for dependency connections) included the module path. This module path is automatically prepended to the name. This means that probably every non-root resource for state-only operations (destroys) didn't order properly. This fixes that by omitting the path properly. Multiple tests added to verify both graph correctness as well as a higher level context test. Will backport to 0.8.x
2017-02-07 22:14:38 -06:00
// This tests the ordering of two resources being destroyed that depend
// on each other from only state. GH-11749
func TestApplyGraphBuilder_destroyStateOnly(t *testing.T) {
terraform: Ugly huge change to weave in new State and Plan types Due to how often the state and plan types are referenced throughout Terraform, there isn't a great way to switch them out gradually. As a consequence, this huge commit gets us from the old world to a _compilable_ new world, but still has a large number of known test failures due to key functionality being stubbed out. The stubs here are for anything that interacts with providers, since we now need to do the follow-up work to similarly replace the old terraform.ResourceProvider interface with its replacement in the new "providers" package. That work, along with work to fix the remaining failing tests, will follow in subsequent commits. The aim here was to replace all references to terraform.State and its downstream types with states.State, terraform.Plan with plans.Plan, state.State with statemgr.State, and switch to the new implementations of the state and plan file formats. However, due to the number of times those types are used, this also ended up affecting numerous other parts of core such as terraform.Hook, the backend.Backend interface, and most of the CLI commands. Just as with 5861dbf3fc49b19587a31816eb06f511ab861bb4 before, I apologize in advance to the person who inevitably just found this huge commit while spelunking through the commit history.
2018-08-14 16:24:45 -05:00
changes := &plans.Changes{
Resources: []*plans.ResourceInstanceChangeSrc{
{
Addr: mustResourceInstanceAddr("module.child.test_object.A"),
ChangeSrc: plans.ChangeSrc{
Action: plans.Delete,
},
},
{
Addr: mustResourceInstanceAddr("module.child.test_object.B"),
ChangeSrc: plans.ChangeSrc{
Action: plans.Delete,
terraform: node referenceable name from state shuldn't contain path Fixes #11749 I'm **really** surprised this didn't come up earlier. When only the state is available for a node, the advertised referenceable name (the name used for dependency connections) included the module path. This module path is automatically prepended to the name. This means that probably every non-root resource for state-only operations (destroys) didn't order properly. This fixes that by omitting the path properly. Multiple tests added to verify both graph correctness as well as a higher level context test. Will backport to 0.8.x
2017-02-07 22:14:38 -06:00
},
},
},
}
add state where it's now needed for tests
2019-12-03 15:04:25 -06:00
state := states.NewState()
root := state.EnsureModule(addrs.RootModuleInstance)
child := state.EnsureModule(addrs.RootModuleInstance.Child("child", addrs.NoKey))
root.SetResourceInstanceCurrent(
mustResourceInstanceAddr("test_object.A").Resource,
&states.ResourceInstanceObjectSrc{
Status: states.ObjectReady,
AttrsJSON: []byte(`{"id":"foo"}`),
},
Mildwonkey/tests (#24522) * terraform: add helper functions for creating test state testSetResourceInstanceCurrent and testSetResourceInstanceTainted are wrapper functions around states.Module.SetResourceInstanceCurrent() used to set a resource in state. They work with current, non-deposed resources with no dependencies. testSetResourceInstanceDeposed can be used to set a desosed resource in state. * terraform: update all tests to use modern providers and state
2020-04-01 12:13:40 -05:00
mustProviderConfig(`provider["registry.terraform.io/hashicorp/test"]`),
add state where it's now needed for tests
2019-12-03 15:04:25 -06:00
)
child.SetResourceInstanceCurrent(
mustResourceInstanceAddr("test_object.B").Resource,
&states.ResourceInstanceObjectSrc{
Status: states.ObjectReady,
AttrsJSON: []byte(`{"id":"bar"}`),
terraform: rename mustReourceAddr to mustConfigResourceAddr and add mustAbsResourceAddr there are too many things that can be called resource addrs and it can be hard to find the must* I'm looking for, so I renamed one and added another.
2020-09-24 10:57:43 -05:00
Dependencies: []addrs.ConfigResource{mustConfigResourceAddr("module.child.test_object.A")},
terraform: node referenceable name from state shuldn't contain path Fixes #11749 I'm **really** surprised this didn't come up earlier. When only the state is available for a node, the advertised referenceable name (the name used for dependency connections) included the module path. This module path is automatically prepended to the name. This means that probably every non-root resource for state-only operations (destroys) didn't order properly. This fixes that by omitting the path properly. Multiple tests added to verify both graph correctness as well as a higher level context test. Will backport to 0.8.x
2017-02-07 22:14:38 -06:00
},
Mildwonkey/tests (#24522) * terraform: add helper functions for creating test state testSetResourceInstanceCurrent and testSetResourceInstanceTainted are wrapper functions around states.Module.SetResourceInstanceCurrent() used to set a resource in state. They work with current, non-deposed resources with no dependencies. testSetResourceInstanceDeposed can be used to set a desosed resource in state. * terraform: update all tests to use modern providers and state
2020-04-01 12:13:40 -05:00
mustProviderConfig(`provider["registry.terraform.io/hashicorp/test"]`),
add state where it's now needed for tests
2019-12-03 15:04:25 -06:00
)
terraform: node referenceable name from state shuldn't contain path Fixes #11749 I'm **really** surprised this didn't come up earlier. When only the state is available for a node, the advertised referenceable name (the name used for dependency connections) included the module path. This module path is automatically prepended to the name. This means that probably every non-root resource for state-only operations (destroys) didn't order properly. This fixes that by omitting the path properly. Multiple tests added to verify both graph correctness as well as a higher level context test. Will backport to 0.8.x
2017-02-07 22:14:38 -06:00
b := &ApplyGraphBuilder{
terraform: remove DisableReduce from refresh, plan and apply graphs (#25824)
2020-08-14 13:13:33 -05:00
Config: testModule(t, "empty"),
Changes: changes,
State: state,
Components: simpleMockComponentFactory(),
Schemas: simpleTestSchemas(),
terraform: node referenceable name from state shuldn't contain path Fixes #11749 I'm **really** surprised this didn't come up earlier. When only the state is available for a node, the advertised referenceable name (the name used for dependency connections) included the module path. This module path is automatically prepended to the name. This means that probably every non-root resource for state-only operations (destroys) didn't order properly. This fixes that by omitting the path properly. Multiple tests added to verify both graph correctness as well as a higher level context test. Will backport to 0.8.x
2017-02-07 22:14:38 -06:00
}
terraform: Ugly huge change to weave in new State and Plan types Due to how often the state and plan types are referenced throughout Terraform, there isn't a great way to switch them out gradually. As a consequence, this huge commit gets us from the old world to a _compilable_ new world, but still has a large number of known test failures due to key functionality being stubbed out. The stubs here are for anything that interacts with providers, since we now need to do the follow-up work to similarly replace the old terraform.ResourceProvider interface with its replacement in the new "providers" package. That work, along with work to fix the remaining failing tests, will follow in subsequent commits. The aim here was to replace all references to terraform.State and its downstream types with states.State, terraform.Plan with plans.Plan, state.State with statemgr.State, and switch to the new implementations of the state and plan file formats. However, due to the number of times those types are used, this also ended up affecting numerous other parts of core such as terraform.Hook, the backend.Backend interface, and most of the CLI commands. Just as with 5861dbf3fc49b19587a31816eb06f511ab861bb4 before, I apologize in advance to the person who inevitably just found this huge commit while spelunking through the commit history.
2018-08-14 16:24:45 -05:00
g, diags := b.Build(addrs.RootModuleInstance)
if diags.HasErrors() {
t.Fatalf("err: %s", diags.Err())
terraform: node referenceable name from state shuldn't contain path Fixes #11749 I'm **really** surprised this didn't come up earlier. When only the state is available for a node, the advertised referenceable name (the name used for dependency connections) included the module path. This module path is automatically prepended to the name. This means that probably every non-root resource for state-only operations (destroys) didn't order properly. This fixes that by omitting the path properly. Multiple tests added to verify both graph correctness as well as a higher level context test. Will backport to 0.8.x
2017-02-07 22:14:38 -06:00
}
core: Get tests compiling again After the refactoring to integrate HCL2 many of the tests were no longer using correct types, attribute names, etc. This is a bulk update of all of the tests to make them compile again, with minimal changes otherwise. Although the tests now compile, many of them do not yet pass. The tests will be gradually repaired in subsequent commits, as we continue to complete the refactoring and retrofit work.
2018-05-04 21:24:06 -05:00
if g.Path.String() != addrs.RootModuleInstance.String() {
t.Fatalf("wrong path %q", g.Path.String())
terraform: node referenceable name from state shuldn't contain path Fixes #11749 I'm **really** surprised this didn't come up earlier. When only the state is available for a node, the advertised referenceable name (the name used for dependency connections) included the module path. This module path is automatically prepended to the name. This means that probably every non-root resource for state-only operations (destroys) didn't order properly. This fixes that by omitting the path properly. Multiple tests added to verify both graph correctness as well as a higher level context test. Will backport to 0.8.x
2017-02-07 22:14:38 -06:00
}
testGraphHappensBefore(
t, g,
core: ApplyGraphBuilder tests to use the "test" mock provider These tests now need schema available to run properly, so rather than crafting a separate schema for each of these we'll just use the one created by simpleMockProvider, which contains a resource type called test_object that we'll now use as the basis for all of the tests here.
2018-05-10 17:38:58 -05:00
"module.child.test_object.B (destroy)",
"module.child.test_object.A (destroy)")
terraform: node referenceable name from state shuldn't contain path Fixes #11749 I'm **really** surprised this didn't come up earlier. When only the state is available for a node, the advertised referenceable name (the name used for dependency connections) included the module path. This module path is automatically prepended to the name. This means that probably every non-root resource for state-only operations (destroys) didn't order properly. This fixes that by omitting the path properly. Multiple tests added to verify both graph correctness as well as a higher level context test. Will backport to 0.8.x
2017-02-07 22:14:38 -06:00
}
terraform: apply resource must depend on destroy deps Fixes #10440 This updates the behavior of "apply" resources to depend on the destroy versions of their dependencies. We make an exception to this behavior when the "apply" resource is CBD. This is odd and not 100% correct, but it mimics the behavior of the legacy graphs and avoids us having to do major core work to support the 100% correct solution. I'll explain this in examples... Given the following configuration: resource "null_resource" "a" { count = "${var.count}" } resource "null_resource" "b" { triggers { key = "${join(",", null_resource.a.*.id)}" } } Assume we've successfully created this configuration with count = 2. When going from count = 2 to count = 1, `null_resource.b` should wait for `null_resource.a.1` to destroy. If it doesn't, then it is a race: depending when we interpolate the `triggers.key` attribute of `null_resource.b`, we may get 1 value or 2. If `null_resource.a.1` is destroyed, we'll get 1. Otherwise, we'll get 2. This was the root cause of #10440 In the legacy graphs, `null_resource.b` would depend on the destruction of any `null_resource.a` (orphans, tainted, anything!). This would ensure proper ordering. We mimic that behavior here. The difference is CBD. If `null_resource.b` has CBD enabled, then the ordering **in the legacy graph** becomes: 1. null_resource.b (create) 2. null_resource.b (destroy) 3. null_resource.a (destroy) In this case, the update would always have 2 values for `triggers.key`, even though we were destroying a resource later! This scenario required two `terraform apply` operations. This is what the CBD check is for in this PR. We do this to mimic the behavior of the legacy graph. The correct solution to do one day is to allow splat references (`null_resource.a.*.id`) to happen in parallel and only read up to to the `count` amount in the state. This requires some fairly significant work close to the 0.8 release date, so we can defer this to later and adopt the 0.7.x behavior for now.
2016-12-04 01:44:09 -06:00
// This tests the ordering of destroying a single count of a resource.
func TestApplyGraphBuilder_destroyCount(t *testing.T) {
terraform: Ugly huge change to weave in new State and Plan types Due to how often the state and plan types are referenced throughout Terraform, there isn't a great way to switch them out gradually. As a consequence, this huge commit gets us from the old world to a _compilable_ new world, but still has a large number of known test failures due to key functionality being stubbed out. The stubs here are for anything that interacts with providers, since we now need to do the follow-up work to similarly replace the old terraform.ResourceProvider interface with its replacement in the new "providers" package. That work, along with work to fix the remaining failing tests, will follow in subsequent commits. The aim here was to replace all references to terraform.State and its downstream types with states.State, terraform.Plan with plans.Plan, state.State with statemgr.State, and switch to the new implementations of the state and plan file formats. However, due to the number of times those types are used, this also ended up affecting numerous other parts of core such as terraform.Hook, the backend.Backend interface, and most of the CLI commands. Just as with 5861dbf3fc49b19587a31816eb06f511ab861bb4 before, I apologize in advance to the person who inevitably just found this huge commit while spelunking through the commit history.
2018-08-14 16:24:45 -05:00
changes := &plans.Changes{
Resources: []*plans.ResourceInstanceChangeSrc{
{
Addr: mustResourceInstanceAddr("test_object.A[1]"),
ChangeSrc: plans.ChangeSrc{
Action: plans.Delete,
},
},
{
Addr: mustResourceInstanceAddr("test_object.B"),
ChangeSrc: plans.ChangeSrc{
Action: plans.Update,
terraform: apply resource must depend on destroy deps Fixes #10440 This updates the behavior of "apply" resources to depend on the destroy versions of their dependencies. We make an exception to this behavior when the "apply" resource is CBD. This is odd and not 100% correct, but it mimics the behavior of the legacy graphs and avoids us having to do major core work to support the 100% correct solution. I'll explain this in examples... Given the following configuration: resource "null_resource" "a" { count = "${var.count}" } resource "null_resource" "b" { triggers { key = "${join(",", null_resource.a.*.id)}" } } Assume we've successfully created this configuration with count = 2. When going from count = 2 to count = 1, `null_resource.b` should wait for `null_resource.a.1` to destroy. If it doesn't, then it is a race: depending when we interpolate the `triggers.key` attribute of `null_resource.b`, we may get 1 value or 2. If `null_resource.a.1` is destroyed, we'll get 1. Otherwise, we'll get 2. This was the root cause of #10440 In the legacy graphs, `null_resource.b` would depend on the destruction of any `null_resource.a` (orphans, tainted, anything!). This would ensure proper ordering. We mimic that behavior here. The difference is CBD. If `null_resource.b` has CBD enabled, then the ordering **in the legacy graph** becomes: 1. null_resource.b (create) 2. null_resource.b (destroy) 3. null_resource.a (destroy) In this case, the update would always have 2 values for `triggers.key`, even though we were destroying a resource later! This scenario required two `terraform apply` operations. This is what the CBD check is for in this PR. We do this to mimic the behavior of the legacy graph. The correct solution to do one day is to allow splat references (`null_resource.a.*.id`) to happen in parallel and only read up to to the `count` amount in the state. This requires some fairly significant work close to the 0.8 release date, so we can defer this to later and adopt the 0.7.x behavior for now.
2016-12-04 01:44:09 -06:00
},
},
},
}
fix tests after moving incorrect references The destroy graph builder test requires state in order to be correct, which it didn't have. The other tests hits the edge case where a planned destroy cannot remove outputs, because the apply phase does not know it was created from a destroy.
2020-07-16 08:09:18 -05:00
state := states.NewState()
root := state.RootModule()
addrA := mustResourceInstanceAddr("test_object.A[1]")
root.SetResourceInstanceCurrent(
addrA.Resource,
&states.ResourceInstanceObjectSrc{
Status: states.ObjectReady,
AttrsJSON: []byte(`{"id":"B"}`),
},
mustProviderConfig(`provider["registry.terraform.io/hashicorp/test"]`),
)
root.SetResourceInstanceCurrent(
mustResourceInstanceAddr("test_object.B").Resource,
&states.ResourceInstanceObjectSrc{
Status: states.ObjectReady,
AttrsJSON: []byte(`{"id":"B"}`),
Dependencies: []addrs.ConfigResource{addrA.ContainingResource().Config()},
},
mustProviderConfig(`provider["registry.terraform.io/hashicorp/test"]`),
)
terraform: apply resource must depend on destroy deps Fixes #10440 This updates the behavior of "apply" resources to depend on the destroy versions of their dependencies. We make an exception to this behavior when the "apply" resource is CBD. This is odd and not 100% correct, but it mimics the behavior of the legacy graphs and avoids us having to do major core work to support the 100% correct solution. I'll explain this in examples... Given the following configuration: resource "null_resource" "a" { count = "${var.count}" } resource "null_resource" "b" { triggers { key = "${join(",", null_resource.a.*.id)}" } } Assume we've successfully created this configuration with count = 2. When going from count = 2 to count = 1, `null_resource.b` should wait for `null_resource.a.1` to destroy. If it doesn't, then it is a race: depending when we interpolate the `triggers.key` attribute of `null_resource.b`, we may get 1 value or 2. If `null_resource.a.1` is destroyed, we'll get 1. Otherwise, we'll get 2. This was the root cause of #10440 In the legacy graphs, `null_resource.b` would depend on the destruction of any `null_resource.a` (orphans, tainted, anything!). This would ensure proper ordering. We mimic that behavior here. The difference is CBD. If `null_resource.b` has CBD enabled, then the ordering **in the legacy graph** becomes: 1. null_resource.b (create) 2. null_resource.b (destroy) 3. null_resource.a (destroy) In this case, the update would always have 2 values for `triggers.key`, even though we were destroying a resource later! This scenario required two `terraform apply` operations. This is what the CBD check is for in this PR. We do this to mimic the behavior of the legacy graph. The correct solution to do one day is to allow splat references (`null_resource.a.*.id`) to happen in parallel and only read up to to the `count` amount in the state. This requires some fairly significant work close to the 0.8 release date, so we can defer this to later and adopt the 0.7.x behavior for now.
2016-12-04 01:44:09 -06:00
b := &ApplyGraphBuilder{
finish graph builder test updates
2018-09-25 09:42:44 -05:00
Config: testModule(t, "graph-builder-apply-count"),
Changes: changes,
Components: simpleMockComponentFactory(),
Schemas: simpleTestSchemas(),
fix tests after moving incorrect references The destroy graph builder test requires state in order to be correct, which it didn't have. The other tests hits the edge case where a planned destroy cannot remove outputs, because the apply phase does not know it was created from a destroy.
2020-07-16 08:09:18 -05:00
State: state,
terraform: apply resource must depend on destroy deps Fixes #10440 This updates the behavior of "apply" resources to depend on the destroy versions of their dependencies. We make an exception to this behavior when the "apply" resource is CBD. This is odd and not 100% correct, but it mimics the behavior of the legacy graphs and avoids us having to do major core work to support the 100% correct solution. I'll explain this in examples... Given the following configuration: resource "null_resource" "a" { count = "${var.count}" } resource "null_resource" "b" { triggers { key = "${join(",", null_resource.a.*.id)}" } } Assume we've successfully created this configuration with count = 2. When going from count = 2 to count = 1, `null_resource.b` should wait for `null_resource.a.1` to destroy. If it doesn't, then it is a race: depending when we interpolate the `triggers.key` attribute of `null_resource.b`, we may get 1 value or 2. If `null_resource.a.1` is destroyed, we'll get 1. Otherwise, we'll get 2. This was the root cause of #10440 In the legacy graphs, `null_resource.b` would depend on the destruction of any `null_resource.a` (orphans, tainted, anything!). This would ensure proper ordering. We mimic that behavior here. The difference is CBD. If `null_resource.b` has CBD enabled, then the ordering **in the legacy graph** becomes: 1. null_resource.b (create) 2. null_resource.b (destroy) 3. null_resource.a (destroy) In this case, the update would always have 2 values for `triggers.key`, even though we were destroying a resource later! This scenario required two `terraform apply` operations. This is what the CBD check is for in this PR. We do this to mimic the behavior of the legacy graph. The correct solution to do one day is to allow splat references (`null_resource.a.*.id`) to happen in parallel and only read up to to the `count` amount in the state. This requires some fairly significant work close to the 0.8 release date, so we can defer this to later and adopt the 0.7.x behavior for now.
2016-12-04 01:44:09 -06:00
}
core: Get tests compiling again After the refactoring to integrate HCL2 many of the tests were no longer using correct types, attribute names, etc. This is a bulk update of all of the tests to make them compile again, with minimal changes otherwise. Although the tests now compile, many of them do not yet pass. The tests will be gradually repaired in subsequent commits, as we continue to complete the refactoring and retrofit work.
2018-05-04 21:24:06 -05:00
g, err := b.Build(addrs.RootModuleInstance)
terraform: apply resource must depend on destroy deps Fixes #10440 This updates the behavior of "apply" resources to depend on the destroy versions of their dependencies. We make an exception to this behavior when the "apply" resource is CBD. This is odd and not 100% correct, but it mimics the behavior of the legacy graphs and avoids us having to do major core work to support the 100% correct solution. I'll explain this in examples... Given the following configuration: resource "null_resource" "a" { count = "${var.count}" } resource "null_resource" "b" { triggers { key = "${join(",", null_resource.a.*.id)}" } } Assume we've successfully created this configuration with count = 2. When going from count = 2 to count = 1, `null_resource.b` should wait for `null_resource.a.1` to destroy. If it doesn't, then it is a race: depending when we interpolate the `triggers.key` attribute of `null_resource.b`, we may get 1 value or 2. If `null_resource.a.1` is destroyed, we'll get 1. Otherwise, we'll get 2. This was the root cause of #10440 In the legacy graphs, `null_resource.b` would depend on the destruction of any `null_resource.a` (orphans, tainted, anything!). This would ensure proper ordering. We mimic that behavior here. The difference is CBD. If `null_resource.b` has CBD enabled, then the ordering **in the legacy graph** becomes: 1. null_resource.b (create) 2. null_resource.b (destroy) 3. null_resource.a (destroy) In this case, the update would always have 2 values for `triggers.key`, even though we were destroying a resource later! This scenario required two `terraform apply` operations. This is what the CBD check is for in this PR. We do this to mimic the behavior of the legacy graph. The correct solution to do one day is to allow splat references (`null_resource.a.*.id`) to happen in parallel and only read up to to the `count` amount in the state. This requires some fairly significant work close to the 0.8 release date, so we can defer this to later and adopt the 0.7.x behavior for now.
2016-12-04 01:44:09 -06:00
if err != nil {
t.Fatalf("err: %s", err)
}
core: Get tests compiling again After the refactoring to integrate HCL2 many of the tests were no longer using correct types, attribute names, etc. This is a bulk update of all of the tests to make them compile again, with minimal changes otherwise. Although the tests now compile, many of them do not yet pass. The tests will be gradually repaired in subsequent commits, as we continue to complete the refactoring and retrofit work.
2018-05-04 21:24:06 -05:00
if g.Path.String() != addrs.RootModuleInstance.String() {
t.Fatalf("wrong module path %q", g.Path)
terraform: apply resource must depend on destroy deps Fixes #10440 This updates the behavior of "apply" resources to depend on the destroy versions of their dependencies. We make an exception to this behavior when the "apply" resource is CBD. This is odd and not 100% correct, but it mimics the behavior of the legacy graphs and avoids us having to do major core work to support the 100% correct solution. I'll explain this in examples... Given the following configuration: resource "null_resource" "a" { count = "${var.count}" } resource "null_resource" "b" { triggers { key = "${join(",", null_resource.a.*.id)}" } } Assume we've successfully created this configuration with count = 2. When going from count = 2 to count = 1, `null_resource.b` should wait for `null_resource.a.1` to destroy. If it doesn't, then it is a race: depending when we interpolate the `triggers.key` attribute of `null_resource.b`, we may get 1 value or 2. If `null_resource.a.1` is destroyed, we'll get 1. Otherwise, we'll get 2. This was the root cause of #10440 In the legacy graphs, `null_resource.b` would depend on the destruction of any `null_resource.a` (orphans, tainted, anything!). This would ensure proper ordering. We mimic that behavior here. The difference is CBD. If `null_resource.b` has CBD enabled, then the ordering **in the legacy graph** becomes: 1. null_resource.b (create) 2. null_resource.b (destroy) 3. null_resource.a (destroy) In this case, the update would always have 2 values for `triggers.key`, even though we were destroying a resource later! This scenario required two `terraform apply` operations. This is what the CBD check is for in this PR. We do this to mimic the behavior of the legacy graph. The correct solution to do one day is to allow splat references (`null_resource.a.*.id`) to happen in parallel and only read up to to the `count` amount in the state. This requires some fairly significant work close to the 0.8 release date, so we can defer this to later and adopt the 0.7.x behavior for now.
2016-12-04 01:44:09 -06:00
}
actual := strings.TrimSpace(g.String())
expected := strings.TrimSpace(testApplyGraphBuilderDestroyCountStr)
if actual != expected {
core: ApplyGraphBuilder tests to use the "test" mock provider These tests now need schema available to run properly, so rather than crafting a separate schema for each of these we'll just use the one created by simpleMockProvider, which contains a resource type called test_object that we'll now use as the basis for all of the tests here.
2018-05-10 17:38:58 -05:00
t.Fatalf("wrong result\n\ngot:\n%s\n\nwant:\n%s", actual, expected)
terraform: apply resource must depend on destroy deps Fixes #10440 This updates the behavior of "apply" resources to depend on the destroy versions of their dependencies. We make an exception to this behavior when the "apply" resource is CBD. This is odd and not 100% correct, but it mimics the behavior of the legacy graphs and avoids us having to do major core work to support the 100% correct solution. I'll explain this in examples... Given the following configuration: resource "null_resource" "a" { count = "${var.count}" } resource "null_resource" "b" { triggers { key = "${join(",", null_resource.a.*.id)}" } } Assume we've successfully created this configuration with count = 2. When going from count = 2 to count = 1, `null_resource.b` should wait for `null_resource.a.1` to destroy. If it doesn't, then it is a race: depending when we interpolate the `triggers.key` attribute of `null_resource.b`, we may get 1 value or 2. If `null_resource.a.1` is destroyed, we'll get 1. Otherwise, we'll get 2. This was the root cause of #10440 In the legacy graphs, `null_resource.b` would depend on the destruction of any `null_resource.a` (orphans, tainted, anything!). This would ensure proper ordering. We mimic that behavior here. The difference is CBD. If `null_resource.b` has CBD enabled, then the ordering **in the legacy graph** becomes: 1. null_resource.b (create) 2. null_resource.b (destroy) 3. null_resource.a (destroy) In this case, the update would always have 2 values for `triggers.key`, even though we were destroying a resource later! This scenario required two `terraform apply` operations. This is what the CBD check is for in this PR. We do this to mimic the behavior of the legacy graph. The correct solution to do one day is to allow splat references (`null_resource.a.*.id`) to happen in parallel and only read up to to the `count` amount in the state. This requires some fairly significant work close to the 0.8 release date, so we can defer this to later and adopt the 0.7.x behavior for now.
2016-12-04 01:44:09 -06:00
}
}
terraform: destroy edges should take into account module variables Fixes #10729 Destruction ordering wasn't taking into account ordering implied through variables across module boundaries. This is because to build the destruction ordering we create a non-destruction graph to determine the _creation_ ordering (to properly flip edges). This creation graph we create wasn't including module variables. This PR adds that transform to the graph.
2016-12-14 23:39:13 -06:00
func TestApplyGraphBuilder_moduleDestroy(t *testing.T) {
terraform: Ugly huge change to weave in new State and Plan types Due to how often the state and plan types are referenced throughout Terraform, there isn't a great way to switch them out gradually. As a consequence, this huge commit gets us from the old world to a _compilable_ new world, but still has a large number of known test failures due to key functionality being stubbed out. The stubs here are for anything that interacts with providers, since we now need to do the follow-up work to similarly replace the old terraform.ResourceProvider interface with its replacement in the new "providers" package. That work, along with work to fix the remaining failing tests, will follow in subsequent commits. The aim here was to replace all references to terraform.State and its downstream types with states.State, terraform.Plan with plans.Plan, state.State with statemgr.State, and switch to the new implementations of the state and plan file formats. However, due to the number of times those types are used, this also ended up affecting numerous other parts of core such as terraform.Hook, the backend.Backend interface, and most of the CLI commands. Just as with 5861dbf3fc49b19587a31816eb06f511ab861bb4 before, I apologize in advance to the person who inevitably just found this huge commit while spelunking through the commit history.
2018-08-14 16:24:45 -05:00
changes := &plans.Changes{
Resources: []*plans.ResourceInstanceChangeSrc{
{
Addr: mustResourceInstanceAddr("module.A.test_object.foo"),
ChangeSrc: plans.ChangeSrc{
Action: plans.Delete,
terraform: destroy edges should take into account module variables Fixes #10729 Destruction ordering wasn't taking into account ordering implied through variables across module boundaries. This is because to build the destruction ordering we create a non-destruction graph to determine the _creation_ ordering (to properly flip edges). This creation graph we create wasn't including module variables. This PR adds that transform to the graph.
2016-12-14 23:39:13 -06:00
},
},
terraform: Ugly huge change to weave in new State and Plan types Due to how often the state and plan types are referenced throughout Terraform, there isn't a great way to switch them out gradually. As a consequence, this huge commit gets us from the old world to a _compilable_ new world, but still has a large number of known test failures due to key functionality being stubbed out. The stubs here are for anything that interacts with providers, since we now need to do the follow-up work to similarly replace the old terraform.ResourceProvider interface with its replacement in the new "providers" package. That work, along with work to fix the remaining failing tests, will follow in subsequent commits. The aim here was to replace all references to terraform.State and its downstream types with states.State, terraform.Plan with plans.Plan, state.State with statemgr.State, and switch to the new implementations of the state and plan file formats. However, due to the number of times those types are used, this also ended up affecting numerous other parts of core such as terraform.Hook, the backend.Backend interface, and most of the CLI commands. Just as with 5861dbf3fc49b19587a31816eb06f511ab861bb4 before, I apologize in advance to the person who inevitably just found this huge commit while spelunking through the commit history.
2018-08-14 16:24:45 -05:00
{
Addr: mustResourceInstanceAddr("module.B.test_object.foo"),
ChangeSrc: plans.ChangeSrc{
Action: plans.Delete,
terraform: destroy edges should take into account module variables Fixes #10729 Destruction ordering wasn't taking into account ordering implied through variables across module boundaries. This is because to build the destruction ordering we create a non-destruction graph to determine the _creation_ ordering (to properly flip edges). This creation graph we create wasn't including module variables. This PR adds that transform to the graph.
2016-12-14 23:39:13 -06:00
},
},
},
}
add state where it's now needed for tests
2019-12-03 15:04:25 -06:00
state := states.NewState()
modA := state.EnsureModule(addrs.RootModuleInstance.Child("A", addrs.NoKey))
modA.SetResourceInstanceCurrent(
mustResourceInstanceAddr("test_object.foo").Resource,
&states.ResourceInstanceObjectSrc{
Status: states.ObjectReady,
AttrsJSON: []byte(`{"id":"foo"}`),
},
Mildwonkey/tests (#24522) * terraform: add helper functions for creating test state testSetResourceInstanceCurrent and testSetResourceInstanceTainted are wrapper functions around states.Module.SetResourceInstanceCurrent() used to set a resource in state. They work with current, non-deposed resources with no dependencies. testSetResourceInstanceDeposed can be used to set a desosed resource in state. * terraform: update all tests to use modern providers and state
2020-04-01 12:13:40 -05:00
mustProviderConfig(`provider["registry.terraform.io/hashicorp/test"]`),
add state where it's now needed for tests
2019-12-03 15:04:25 -06:00
)
modB := state.EnsureModule(addrs.RootModuleInstance.Child("B", addrs.NoKey))
modB.SetResourceInstanceCurrent(
mustResourceInstanceAddr("test_object.foo").Resource,
&states.ResourceInstanceObjectSrc{
Status: states.ObjectReady,
AttrsJSON: []byte(`{"id":"foo","value":"foo"}`),
terraform: rename mustReourceAddr to mustConfigResourceAddr and add mustAbsResourceAddr there are too many things that can be called resource addrs and it can be hard to find the must* I'm looking for, so I renamed one and added another.
2020-09-24 10:57:43 -05:00
Dependencies: []addrs.ConfigResource{mustConfigResourceAddr("module.A.test_object.foo")},
add state where it's now needed for tests
2019-12-03 15:04:25 -06:00
},
Mildwonkey/tests (#24522) * terraform: add helper functions for creating test state testSetResourceInstanceCurrent and testSetResourceInstanceTainted are wrapper functions around states.Module.SetResourceInstanceCurrent() used to set a resource in state. They work with current, non-deposed resources with no dependencies. testSetResourceInstanceDeposed can be used to set a desosed resource in state. * terraform: update all tests to use modern providers and state
2020-04-01 12:13:40 -05:00
mustProviderConfig(`provider["registry.terraform.io/hashicorp/test"]`),
add state where it's now needed for tests
2019-12-03 15:04:25 -06:00
)
terraform: destroy edges should take into account module variables Fixes #10729 Destruction ordering wasn't taking into account ordering implied through variables across module boundaries. This is because to build the destruction ordering we create a non-destruction graph to determine the _creation_ ordering (to properly flip edges). This creation graph we create wasn't including module variables. This PR adds that transform to the graph.
2016-12-14 23:39:13 -06:00
b := &ApplyGraphBuilder{
core: ApplyGraphBuilder tests to use the "test" mock provider These tests now need schema available to run properly, so rather than crafting a separate schema for each of these we'll just use the one created by simpleMockProvider, which contains a resource type called test_object that we'll now use as the basis for all of the tests here.
2018-05-10 17:38:58 -05:00
Config: testModule(t, "graph-builder-apply-module-destroy"),
terraform: Ugly huge change to weave in new State and Plan types Due to how often the state and plan types are referenced throughout Terraform, there isn't a great way to switch them out gradually. As a consequence, this huge commit gets us from the old world to a _compilable_ new world, but still has a large number of known test failures due to key functionality being stubbed out. The stubs here are for anything that interacts with providers, since we now need to do the follow-up work to similarly replace the old terraform.ResourceProvider interface with its replacement in the new "providers" package. That work, along with work to fix the remaining failing tests, will follow in subsequent commits. The aim here was to replace all references to terraform.State and its downstream types with states.State, terraform.Plan with plans.Plan, state.State with statemgr.State, and switch to the new implementations of the state and plan file formats. However, due to the number of times those types are used, this also ended up affecting numerous other parts of core such as terraform.Hook, the backend.Backend interface, and most of the CLI commands. Just as with 5861dbf3fc49b19587a31816eb06f511ab861bb4 before, I apologize in advance to the person who inevitably just found this huge commit while spelunking through the commit history.
2018-08-14 16:24:45 -05:00
Changes: changes,
core: ApplyGraphBuilder tests to use the "test" mock provider These tests now need schema available to run properly, so rather than crafting a separate schema for each of these we'll just use the one created by simpleMockProvider, which contains a resource type called test_object that we'll now use as the basis for all of the tests here.
2018-05-10 17:38:58 -05:00
Components: simpleMockComponentFactory(),
core: Fetch schemas during context construction Previously we fetched schemas during the AttachSchemaTransformer, potentially multiple times as that was re-run for each graph built. Now we fetch the schemas just once during context construction, passing that result into each of the graph builders. This only addresses the schema accesses during graph construction. We're still separately loading schemas during the main walk for evaluation purposes. This will be addressed in a later commit.
2018-05-31 14:39:45 -05:00
Schemas: simpleTestSchemas(),
add state where it's now needed for tests
2019-12-03 15:04:25 -06:00
State: state,
terraform: destroy edges should take into account module variables Fixes #10729 Destruction ordering wasn't taking into account ordering implied through variables across module boundaries. This is because to build the destruction ordering we create a non-destruction graph to determine the _creation_ ordering (to properly flip edges). This creation graph we create wasn't including module variables. This PR adds that transform to the graph.
2016-12-14 23:39:13 -06:00
}
core: Get tests compiling again After the refactoring to integrate HCL2 many of the tests were no longer using correct types, attribute names, etc. This is a bulk update of all of the tests to make them compile again, with minimal changes otherwise. Although the tests now compile, many of them do not yet pass. The tests will be gradually repaired in subsequent commits, as we continue to complete the refactoring and retrofit work.
2018-05-04 21:24:06 -05:00
g, err := b.Build(addrs.RootModuleInstance)
terraform: destroy edges should take into account module variables Fixes #10729 Destruction ordering wasn't taking into account ordering implied through variables across module boundaries. This is because to build the destruction ordering we create a non-destruction graph to determine the _creation_ ordering (to properly flip edges). This creation graph we create wasn't including module variables. This PR adds that transform to the graph.
2016-12-14 23:39:13 -06:00
if err != nil {
t.Fatalf("err: %s", err)
}
testGraphHappensBefore(
t, g,
core: ApplyGraphBuilder tests to use the "test" mock provider These tests now need schema available to run properly, so rather than crafting a separate schema for each of these we'll just use the one created by simpleMockProvider, which contains a resource type called test_object that we'll now use as the basis for all of the tests here.
2018-05-10 17:38:58 -05:00
"module.B.test_object.foo (destroy)",
"module.A.test_object.foo (destroy)",
)
terraform: destroy edges should take into account module variables Fixes #10729 Destruction ordering wasn't taking into account ordering implied through variables across module boundaries. This is because to build the destruction ordering we create a non-destruction graph to determine the _creation_ ordering (to properly flip edges). This creation graph we create wasn't including module variables. This PR adds that transform to the graph.
2016-12-14 23:39:13 -06:00
}
terraform: run destroy provisioners on destroy
2017-01-20 20:07:51 -06:00
func TestApplyGraphBuilder_provisioner(t *testing.T) {
terraform: Ugly huge change to weave in new State and Plan types Due to how often the state and plan types are referenced throughout Terraform, there isn't a great way to switch them out gradually. As a consequence, this huge commit gets us from the old world to a _compilable_ new world, but still has a large number of known test failures due to key functionality being stubbed out. The stubs here are for anything that interacts with providers, since we now need to do the follow-up work to similarly replace the old terraform.ResourceProvider interface with its replacement in the new "providers" package. That work, along with work to fix the remaining failing tests, will follow in subsequent commits. The aim here was to replace all references to terraform.State and its downstream types with states.State, terraform.Plan with plans.Plan, state.State with statemgr.State, and switch to the new implementations of the state and plan file formats. However, due to the number of times those types are used, this also ended up affecting numerous other parts of core such as terraform.Hook, the backend.Backend interface, and most of the CLI commands. Just as with 5861dbf3fc49b19587a31816eb06f511ab861bb4 before, I apologize in advance to the person who inevitably just found this huge commit while spelunking through the commit history.
2018-08-14 16:24:45 -05:00
changes := &plans.Changes{
Resources: []*plans.ResourceInstanceChangeSrc{
{
Addr: mustResourceInstanceAddr("test_object.foo"),
ChangeSrc: plans.ChangeSrc{
Action: plans.Create,
terraform: run destroy provisioners on destroy
2017-01-20 20:07:51 -06:00
},
},
},
}
b := &ApplyGraphBuilder{
core: ApplyGraphBuilder tests to use the "test" mock provider These tests now need schema available to run properly, so rather than crafting a separate schema for each of these we'll just use the one created by simpleMockProvider, which contains a resource type called test_object that we'll now use as the basis for all of the tests here.
2018-05-10 17:38:58 -05:00
Config: testModule(t, "graph-builder-apply-provisioner"),
terraform: Ugly huge change to weave in new State and Plan types Due to how often the state and plan types are referenced throughout Terraform, there isn't a great way to switch them out gradually. As a consequence, this huge commit gets us from the old world to a _compilable_ new world, but still has a large number of known test failures due to key functionality being stubbed out. The stubs here are for anything that interacts with providers, since we now need to do the follow-up work to similarly replace the old terraform.ResourceProvider interface with its replacement in the new "providers" package. That work, along with work to fix the remaining failing tests, will follow in subsequent commits. The aim here was to replace all references to terraform.State and its downstream types with states.State, terraform.Plan with plans.Plan, state.State with statemgr.State, and switch to the new implementations of the state and plan file formats. However, due to the number of times those types are used, this also ended up affecting numerous other parts of core such as terraform.Hook, the backend.Backend interface, and most of the CLI commands. Just as with 5861dbf3fc49b19587a31816eb06f511ab861bb4 before, I apologize in advance to the person who inevitably just found this huge commit while spelunking through the commit history.
2018-08-14 16:24:45 -05:00
Changes: changes,
core: ApplyGraphBuilder tests to use the "test" mock provider These tests now need schema available to run properly, so rather than crafting a separate schema for each of these we'll just use the one created by simpleMockProvider, which contains a resource type called test_object that we'll now use as the basis for all of the tests here.
2018-05-10 17:38:58 -05:00
Components: simpleMockComponentFactory(),
core: Fetch schemas during context construction Previously we fetched schemas during the AttachSchemaTransformer, potentially multiple times as that was re-run for each graph built. Now we fetch the schemas just once during context construction, passing that result into each of the graph builders. This only addresses the schema accesses during graph construction. We're still separately loading schemas during the main walk for evaluation purposes. This will be addressed in a later commit.
2018-05-31 14:39:45 -05:00
Schemas: simpleTestSchemas(),
terraform: run destroy provisioners on destroy
2017-01-20 20:07:51 -06:00
}
core: Get tests compiling again After the refactoring to integrate HCL2 many of the tests were no longer using correct types, attribute names, etc. This is a bulk update of all of the tests to make them compile again, with minimal changes otherwise. Although the tests now compile, many of them do not yet pass. The tests will be gradually repaired in subsequent commits, as we continue to complete the refactoring and retrofit work.
2018-05-04 21:24:06 -05:00
g, err := b.Build(addrs.RootModuleInstance)
terraform: run destroy provisioners on destroy
2017-01-20 20:07:51 -06:00
if err != nil {
t.Fatalf("err: %s", err)
}
core: ApplyGraphBuilder tests to use the "test" mock provider These tests now need schema available to run properly, so rather than crafting a separate schema for each of these we'll just use the one created by simpleMockProvider, which contains a resource type called test_object that we'll now use as the basis for all of the tests here.
2018-05-10 17:38:58 -05:00
testGraphContains(t, g, "provisioner.test")
terraform: run destroy provisioners on destroy
2017-01-20 20:07:51 -06:00
testGraphHappensBefore(
t, g,
core: ApplyGraphBuilder tests to use the "test" mock provider These tests now need schema available to run properly, so rather than crafting a separate schema for each of these we'll just use the one created by simpleMockProvider, which contains a resource type called test_object that we'll now use as the basis for all of the tests here.
2018-05-10 17:38:58 -05:00
"provisioner.test",
"test_object.foo",
)
terraform: run destroy provisioners on destroy
2017-01-20 20:07:51 -06:00
}
func TestApplyGraphBuilder_provisionerDestroy(t *testing.T) {
terraform: Ugly huge change to weave in new State and Plan types Due to how often the state and plan types are referenced throughout Terraform, there isn't a great way to switch them out gradually. As a consequence, this huge commit gets us from the old world to a _compilable_ new world, but still has a large number of known test failures due to key functionality being stubbed out. The stubs here are for anything that interacts with providers, since we now need to do the follow-up work to similarly replace the old terraform.ResourceProvider interface with its replacement in the new "providers" package. That work, along with work to fix the remaining failing tests, will follow in subsequent commits. The aim here was to replace all references to terraform.State and its downstream types with states.State, terraform.Plan with plans.Plan, state.State with statemgr.State, and switch to the new implementations of the state and plan file formats. However, due to the number of times those types are used, this also ended up affecting numerous other parts of core such as terraform.Hook, the backend.Backend interface, and most of the CLI commands. Just as with 5861dbf3fc49b19587a31816eb06f511ab861bb4 before, I apologize in advance to the person who inevitably just found this huge commit while spelunking through the commit history.
2018-08-14 16:24:45 -05:00
changes := &plans.Changes{
Resources: []*plans.ResourceInstanceChangeSrc{
{
Addr: mustResourceInstanceAddr("test_object.foo"),
ChangeSrc: plans.ChangeSrc{
Action: plans.Delete,
terraform: run destroy provisioners on destroy
2017-01-20 20:07:51 -06:00
},
},
},
}
b := &ApplyGraphBuilder{
core: ApplyGraphBuilder tests to use the "test" mock provider These tests now need schema available to run properly, so rather than crafting a separate schema for each of these we'll just use the one created by simpleMockProvider, which contains a resource type called test_object that we'll now use as the basis for all of the tests here.
2018-05-10 17:38:58 -05:00
Config: testModule(t, "graph-builder-apply-provisioner"),
terraform: Ugly huge change to weave in new State and Plan types Due to how often the state and plan types are referenced throughout Terraform, there isn't a great way to switch them out gradually. As a consequence, this huge commit gets us from the old world to a _compilable_ new world, but still has a large number of known test failures due to key functionality being stubbed out. The stubs here are for anything that interacts with providers, since we now need to do the follow-up work to similarly replace the old terraform.ResourceProvider interface with its replacement in the new "providers" package. That work, along with work to fix the remaining failing tests, will follow in subsequent commits. The aim here was to replace all references to terraform.State and its downstream types with states.State, terraform.Plan with plans.Plan, state.State with statemgr.State, and switch to the new implementations of the state and plan file formats. However, due to the number of times those types are used, this also ended up affecting numerous other parts of core such as terraform.Hook, the backend.Backend interface, and most of the CLI commands. Just as with 5861dbf3fc49b19587a31816eb06f511ab861bb4 before, I apologize in advance to the person who inevitably just found this huge commit while spelunking through the commit history.
2018-08-14 16:24:45 -05:00
Changes: changes,
core: ApplyGraphBuilder tests to use the "test" mock provider These tests now need schema available to run properly, so rather than crafting a separate schema for each of these we'll just use the one created by simpleMockProvider, which contains a resource type called test_object that we'll now use as the basis for all of the tests here.
2018-05-10 17:38:58 -05:00
Components: simpleMockComponentFactory(),
core: Fetch schemas during context construction Previously we fetched schemas during the AttachSchemaTransformer, potentially multiple times as that was re-run for each graph built. Now we fetch the schemas just once during context construction, passing that result into each of the graph builders. This only addresses the schema accesses during graph construction. We're still separately loading schemas during the main walk for evaluation purposes. This will be addressed in a later commit.
2018-05-31 14:39:45 -05:00
Schemas: simpleTestSchemas(),
terraform: run destroy provisioners on destroy
2017-01-20 20:07:51 -06:00
}
core: Get tests compiling again After the refactoring to integrate HCL2 many of the tests were no longer using correct types, attribute names, etc. This is a bulk update of all of the tests to make them compile again, with minimal changes otherwise. Although the tests now compile, many of them do not yet pass. The tests will be gradually repaired in subsequent commits, as we continue to complete the refactoring and retrofit work.
2018-05-04 21:24:06 -05:00
g, err := b.Build(addrs.RootModuleInstance)
terraform: run destroy provisioners on destroy
2017-01-20 20:07:51 -06:00
if err != nil {
t.Fatalf("err: %s", err)
}
core: ApplyGraphBuilder tests to use the "test" mock provider These tests now need schema available to run properly, so rather than crafting a separate schema for each of these we'll just use the one created by simpleMockProvider, which contains a resource type called test_object that we'll now use as the basis for all of the tests here.
2018-05-10 17:38:58 -05:00
testGraphContains(t, g, "provisioner.test")
terraform: run destroy provisioners on destroy
2017-01-20 20:07:51 -06:00
testGraphHappensBefore(
t, g,
core: ApplyGraphBuilder tests to use the "test" mock provider These tests now need schema available to run properly, so rather than crafting a separate schema for each of these we'll just use the one created by simpleMockProvider, which contains a resource type called test_object that we'll now use as the basis for all of the tests here.
2018-05-10 17:38:58 -05:00
"provisioner.test",
"test_object.foo (destroy)",
)
terraform: run destroy provisioners on destroy
2017-01-20 20:07:51 -06:00
}
terraform: outputs should not be included if not targeted Fixes #10911 Outputs that aren't targeted shouldn't be included in the graph. This requires passing targets to the apply graph. This is unfortunate but long term should be removable since I'd like to move output changes to the diff as well.
2017-02-13 14:52:45 -06:00
func TestApplyGraphBuilder_targetModule(t *testing.T) {
terraform: Ugly huge change to weave in new State and Plan types Due to how often the state and plan types are referenced throughout Terraform, there isn't a great way to switch them out gradually. As a consequence, this huge commit gets us from the old world to a _compilable_ new world, but still has a large number of known test failures due to key functionality being stubbed out. The stubs here are for anything that interacts with providers, since we now need to do the follow-up work to similarly replace the old terraform.ResourceProvider interface with its replacement in the new "providers" package. That work, along with work to fix the remaining failing tests, will follow in subsequent commits. The aim here was to replace all references to terraform.State and its downstream types with states.State, terraform.Plan with plans.Plan, state.State with statemgr.State, and switch to the new implementations of the state and plan file formats. However, due to the number of times those types are used, this also ended up affecting numerous other parts of core such as terraform.Hook, the backend.Backend interface, and most of the CLI commands. Just as with 5861dbf3fc49b19587a31816eb06f511ab861bb4 before, I apologize in advance to the person who inevitably just found this huge commit while spelunking through the commit history.
2018-08-14 16:24:45 -05:00
changes := &plans.Changes{
Resources: []*plans.ResourceInstanceChangeSrc{
{
Addr: mustResourceInstanceAddr("test_object.foo"),
ChangeSrc: plans.ChangeSrc{
Action: plans.Update,
terraform: outputs should not be included if not targeted Fixes #10911 Outputs that aren't targeted shouldn't be included in the graph. This requires passing targets to the apply graph. This is unfortunate but long term should be removable since I'd like to move output changes to the diff as well.
2017-02-13 14:52:45 -06:00
},
},
terraform: Ugly huge change to weave in new State and Plan types Due to how often the state and plan types are referenced throughout Terraform, there isn't a great way to switch them out gradually. As a consequence, this huge commit gets us from the old world to a _compilable_ new world, but still has a large number of known test failures due to key functionality being stubbed out. The stubs here are for anything that interacts with providers, since we now need to do the follow-up work to similarly replace the old terraform.ResourceProvider interface with its replacement in the new "providers" package. That work, along with work to fix the remaining failing tests, will follow in subsequent commits. The aim here was to replace all references to terraform.State and its downstream types with states.State, terraform.Plan with plans.Plan, state.State with statemgr.State, and switch to the new implementations of the state and plan file formats. However, due to the number of times those types are used, this also ended up affecting numerous other parts of core such as terraform.Hook, the backend.Backend interface, and most of the CLI commands. Just as with 5861dbf3fc49b19587a31816eb06f511ab861bb4 before, I apologize in advance to the person who inevitably just found this huge commit while spelunking through the commit history.
2018-08-14 16:24:45 -05:00
{
Addr: mustResourceInstanceAddr("module.child2.test_object.foo"),
ChangeSrc: plans.ChangeSrc{
Action: plans.Update,
terraform: outputs should not be included if not targeted Fixes #10911 Outputs that aren't targeted shouldn't be included in the graph. This requires passing targets to the apply graph. This is unfortunate but long term should be removable since I'd like to move output changes to the diff as well.
2017-02-13 14:52:45 -06:00
},
},
},
}
b := &ApplyGraphBuilder{
core: ApplyGraphBuilder tests to use the "test" mock provider These tests now need schema available to run properly, so rather than crafting a separate schema for each of these we'll just use the one created by simpleMockProvider, which contains a resource type called test_object that we'll now use as the basis for all of the tests here.
2018-05-10 17:38:58 -05:00
Config: testModule(t, "graph-builder-apply-target-module"),
terraform: Ugly huge change to weave in new State and Plan types Due to how often the state and plan types are referenced throughout Terraform, there isn't a great way to switch them out gradually. As a consequence, this huge commit gets us from the old world to a _compilable_ new world, but still has a large number of known test failures due to key functionality being stubbed out. The stubs here are for anything that interacts with providers, since we now need to do the follow-up work to similarly replace the old terraform.ResourceProvider interface with its replacement in the new "providers" package. That work, along with work to fix the remaining failing tests, will follow in subsequent commits. The aim here was to replace all references to terraform.State and its downstream types with states.State, terraform.Plan with plans.Plan, state.State with statemgr.State, and switch to the new implementations of the state and plan file formats. However, due to the number of times those types are used, this also ended up affecting numerous other parts of core such as terraform.Hook, the backend.Backend interface, and most of the CLI commands. Just as with 5861dbf3fc49b19587a31816eb06f511ab861bb4 before, I apologize in advance to the person who inevitably just found this huge commit while spelunking through the commit history.
2018-08-14 16:24:45 -05:00
Changes: changes,
core: ApplyGraphBuilder tests to use the "test" mock provider These tests now need schema available to run properly, so rather than crafting a separate schema for each of these we'll just use the one created by simpleMockProvider, which contains a resource type called test_object that we'll now use as the basis for all of the tests here.
2018-05-10 17:38:58 -05:00
Components: simpleMockComponentFactory(),
core: Fetch schemas during context construction Previously we fetched schemas during the AttachSchemaTransformer, potentially multiple times as that was re-run for each graph built. Now we fetch the schemas just once during context construction, passing that result into each of the graph builders. This only addresses the schema accesses during graph construction. We're still separately loading schemas during the main walk for evaluation purposes. This will be addressed in a later commit.
2018-05-31 14:39:45 -05:00
Schemas: simpleTestSchemas(),
core: Get tests compiling again After the refactoring to integrate HCL2 many of the tests were no longer using correct types, attribute names, etc. This is a bulk update of all of the tests to make them compile again, with minimal changes otherwise. Although the tests now compile, many of them do not yet pass. The tests will be gradually repaired in subsequent commits, as we continue to complete the refactoring and retrofit work.
2018-05-04 21:24:06 -05:00
Targets: []addrs.Targetable{
addrs.RootModuleInstance.Child("child2", addrs.NoKey),
},
terraform: outputs should not be included if not targeted Fixes #10911 Outputs that aren't targeted shouldn't be included in the graph. This requires passing targets to the apply graph. This is unfortunate but long term should be removable since I'd like to move output changes to the diff as well.
2017-02-13 14:52:45 -06:00
}
core: Get tests compiling again After the refactoring to integrate HCL2 many of the tests were no longer using correct types, attribute names, etc. This is a bulk update of all of the tests to make them compile again, with minimal changes otherwise. Although the tests now compile, many of them do not yet pass. The tests will be gradually repaired in subsequent commits, as we continue to complete the refactoring and retrofit work.
2018-05-04 21:24:06 -05:00
g, err := b.Build(addrs.RootModuleInstance)
terraform: outputs should not be included if not targeted Fixes #10911 Outputs that aren't targeted shouldn't be included in the graph. This requires passing targets to the apply graph. This is unfortunate but long term should be removable since I'd like to move output changes to the diff as well.
2017-02-13 14:52:45 -06:00
if err != nil {
t.Fatalf("err: %s", err)
}
testGraphNotContains(t, g, "module.child1.output.instance_id")
}
failing test for update from orphaned instance Updates resulting from orphaned instances should happen after the deletion of the instances.
2019-10-29 09:57:38 -05:00
// Ensure that an update resulting from the removal of a resource happens after
// that resource is destroyed.
func TestApplyGraphBuilder_updateFromOrphan(t *testing.T) {
schemas := simpleTestSchemas()
Mildwonkey/tests (#24522) * terraform: add helper functions for creating test state testSetResourceInstanceCurrent and testSetResourceInstanceTainted are wrapper functions around states.Module.SetResourceInstanceCurrent() used to set a resource in state. They work with current, non-deposed resources with no dependencies. testSetResourceInstanceDeposed can be used to set a desosed resource in state. * terraform: update all tests to use modern providers and state
2020-04-01 12:13:40 -05:00
instanceSchema := schemas.Providers[addrs.NewDefaultProvider("test")].ResourceTypes["test_object"]
failing test for update from orphaned instance Updates resulting from orphaned instances should happen after the deletion of the instances.
2019-10-29 09:57:38 -05:00
bBefore, _ := plans.NewDynamicValue(
cty.ObjectVal(map[string]cty.Value{
"id": cty.StringVal("b_id"),
"test_string": cty.StringVal("a_id"),
}), instanceSchema.ImpliedType())
bAfter, _ := plans.NewDynamicValue(
cty.ObjectVal(map[string]cty.Value{
"id": cty.StringVal("b_id"),
"test_string": cty.StringVal("changed"),
}), instanceSchema.ImpliedType())
changes := &plans.Changes{
Resources: []*plans.ResourceInstanceChangeSrc{
{
Addr: mustResourceInstanceAddr("test_object.a"),
ChangeSrc: plans.ChangeSrc{
Action: plans.Delete,
},
},
{
Addr: mustResourceInstanceAddr("test_object.b"),
ChangeSrc: plans.ChangeSrc{
Action: plans.Update,
Before: bBefore,
After: bAfter,
},
},
},
}
state := states.NewState()
root := state.EnsureModule(addrs.RootModuleInstance)
root.SetResourceInstanceCurrent(
addrs.Resource{
Mode: addrs.ManagedResourceMode,
Type: "test_object",
Name: "a",
}.Instance(addrs.NoKey),
&states.ResourceInstanceObjectSrc{
Status: states.ObjectReady,
AttrsJSON: []byte(`{"id":"a_id"}`),
},
addrs: embed Provider in AbsProviderConfig instead of Type a large refactor to addrs.AbsProviderConfig, embedding the addrs.Provider instead of a Type string. I've added and updated tests, added some Legacy functions to support older state formats and shims, and added a normalization step when reading v4 (current) state files (not the added tests under states/statefile/roundtrip which work with both current and legacy-style AbsProviderConfig strings). The remaining 'fixme' and 'todo' comments are mostly going to be addressed in a subsequent PR and involve looking up a given local provider config's FQN. This is fine for now as we are only working with default assumption.
2020-02-13 14:32:58 -06:00
addrs.AbsProviderConfig{
Mildwonkey/tests (#24522) * terraform: add helper functions for creating test state testSetResourceInstanceCurrent and testSetResourceInstanceTainted are wrapper functions around states.Module.SetResourceInstanceCurrent() used to set a resource in state. They work with current, non-deposed resources with no dependencies. testSetResourceInstanceDeposed can be used to set a desosed resource in state. * terraform: update all tests to use modern providers and state
2020-04-01 12:13:40 -05:00
Provider: addrs.NewDefaultProvider("test"),
convert /terraform to use new provider config Change all ModuleInstances in provider types to plain Modules
2020-03-10 20:21:19 -05:00
Module: addrs.RootModule,
addrs: embed Provider in AbsProviderConfig instead of Type a large refactor to addrs.AbsProviderConfig, embedding the addrs.Provider instead of a Type string. I've added and updated tests, added some Legacy functions to support older state formats and shims, and added a normalization step when reading v4 (current) state files (not the added tests under states/statefile/roundtrip which work with both current and legacy-style AbsProviderConfig strings). The remaining 'fixme' and 'todo' comments are mostly going to be addressed in a subsequent PR and involve looking up a given local provider config's FQN. This is fine for now as we are only working with default assumption.
2020-02-13 14:32:58 -06:00
},
failing test for update from orphaned instance Updates resulting from orphaned instances should happen after the deletion of the instances.
2019-10-29 09:57:38 -05:00
)
root.SetResourceInstanceCurrent(
addrs.Resource{
Mode: addrs.ManagedResourceMode,
Type: "test_object",
Name: "b",
}.Instance(addrs.NoKey),
&states.ResourceInstanceObjectSrc{
Status: states.ObjectReady,
AttrsJSON: []byte(`{"id":"b_id","test_string":"a_id"}`),
use addrs.ConfigResource for dependency tracking We can't get module instances during transformation, so we need to reduce the Dependencies to using `addrs.ConfigResource` for now.
2020-03-23 14:26:18 -05:00
Dependencies: []addrs.ConfigResource{
addrs.ConfigResource{
failing test for update from orphaned instance Updates resulting from orphaned instances should happen after the deletion of the instances.
2019-10-29 09:57:38 -05:00
Resource: addrs.Resource{
Mode: addrs.ManagedResourceMode,
Type: "test_object",
Name: "a",
},
use addrs.ConfigResource for dependency tracking We can't get module instances during transformation, so we need to reduce the Dependencies to using `addrs.ConfigResource` for now.
2020-03-23 14:26:18 -05:00
Module: root.Addr.Module(),
failing test for update from orphaned instance Updates resulting from orphaned instances should happen after the deletion of the instances.
2019-10-29 09:57:38 -05:00
},
},
},
addrs: embed Provider in AbsProviderConfig instead of Type a large refactor to addrs.AbsProviderConfig, embedding the addrs.Provider instead of a Type string. I've added and updated tests, added some Legacy functions to support older state formats and shims, and added a normalization step when reading v4 (current) state files (not the added tests under states/statefile/roundtrip which work with both current and legacy-style AbsProviderConfig strings). The remaining 'fixme' and 'todo' comments are mostly going to be addressed in a subsequent PR and involve looking up a given local provider config's FQN. This is fine for now as we are only working with default assumption.
2020-02-13 14:32:58 -06:00
addrs.AbsProviderConfig{
Mildwonkey/tests (#24522) * terraform: add helper functions for creating test state testSetResourceInstanceCurrent and testSetResourceInstanceTainted are wrapper functions around states.Module.SetResourceInstanceCurrent() used to set a resource in state. They work with current, non-deposed resources with no dependencies. testSetResourceInstanceDeposed can be used to set a desosed resource in state. * terraform: update all tests to use modern providers and state
2020-04-01 12:13:40 -05:00
Provider: addrs.NewDefaultProvider("test"),
convert /terraform to use new provider config Change all ModuleInstances in provider types to plain Modules
2020-03-10 20:21:19 -05:00
Module: addrs.RootModule,
addrs: embed Provider in AbsProviderConfig instead of Type a large refactor to addrs.AbsProviderConfig, embedding the addrs.Provider instead of a Type string. I've added and updated tests, added some Legacy functions to support older state formats and shims, and added a normalization step when reading v4 (current) state files (not the added tests under states/statefile/roundtrip which work with both current and legacy-style AbsProviderConfig strings). The remaining 'fixme' and 'todo' comments are mostly going to be addressed in a subsequent PR and involve looking up a given local provider config's FQN. This is fine for now as we are only working with default assumption.
2020-02-13 14:32:58 -06:00
},
failing test for update from orphaned instance Updates resulting from orphaned instances should happen after the deletion of the instances.
2019-10-29 09:57:38 -05:00
)
b := &ApplyGraphBuilder{
Config: testModule(t, "graph-builder-apply-orphan-update"),
Changes: changes,
Components: simpleMockComponentFactory(),
Schemas: schemas,
State: state,
}
g, err := b.Build(addrs.RootModuleInstance)
if err != nil {
t.Fatalf("err: %s", err)
}
expected := strings.TrimSpace(`
test_object.a (destroy)
test_object.b
test_object.a (destroy)
`)
instanceGraph := filterInstances(g)
use Dependencies to connect creator and destroyer The DestroyEdgeTransformer cannot determine ordering from the graph when the destroyers are from orphaned resources, because there are no references to resolve. The new stored Dependencies provides what we need to connect the instances in this case. We also add the StateDependencies method directly in the GraphNodeResourceInstance interface, since all instances already implement this, and we don't need another optional interface to check. The old code in DestroyEdgeTransformer may no longer be needed in the long run, but that can be determined separately, since too many of the tests start with an incomplete state and rely on the Dependencies being determined from the configuration alone.
2019-10-30 14:59:34 -05:00
got := strings.TrimSpace(instanceGraph.String())
test for CBD instance being removed entirely Even though this is only the destroy half of CreateBeforeDestroy, the resource may still require the same destroy order.
2019-12-12 14:02:26 -06:00
if got != expected {
t.Fatalf("expected:\n%s\ngot:\n%s", expected, got)
}
}
// Ensure that an update resulting from the removal of a resource happens before
// a CBD resource is destroyed.
func TestApplyGraphBuilder_updateFromCBDOrphan(t *testing.T) {
schemas := simpleTestSchemas()
Mildwonkey/tests (#24522) * terraform: add helper functions for creating test state testSetResourceInstanceCurrent and testSetResourceInstanceTainted are wrapper functions around states.Module.SetResourceInstanceCurrent() used to set a resource in state. They work with current, non-deposed resources with no dependencies. testSetResourceInstanceDeposed can be used to set a desosed resource in state. * terraform: update all tests to use modern providers and state
2020-04-01 12:13:40 -05:00
instanceSchema := schemas.Providers[addrs.NewDefaultProvider("test")].ResourceTypes["test_object"]
test for CBD instance being removed entirely Even though this is only the destroy half of CreateBeforeDestroy, the resource may still require the same destroy order.
2019-12-12 14:02:26 -06:00
bBefore, _ := plans.NewDynamicValue(
cty.ObjectVal(map[string]cty.Value{
"id": cty.StringVal("b_id"),
"test_string": cty.StringVal("a_id"),
}), instanceSchema.ImpliedType())
bAfter, _ := plans.NewDynamicValue(
cty.ObjectVal(map[string]cty.Value{
"id": cty.StringVal("b_id"),
"test_string": cty.StringVal("changed"),
}), instanceSchema.ImpliedType())
changes := &plans.Changes{
Resources: []*plans.ResourceInstanceChangeSrc{
{
Addr: mustResourceInstanceAddr("test_object.a"),
ChangeSrc: plans.ChangeSrc{
Action: plans.Delete,
},
},
{
Addr: mustResourceInstanceAddr("test_object.b"),
ChangeSrc: plans.ChangeSrc{
Action: plans.Update,
Before: bBefore,
After: bAfter,
},
},
},
}
state := states.NewState()
root := state.EnsureModule(addrs.RootModuleInstance)
root.SetResourceInstanceCurrent(
addrs.Resource{
Mode: addrs.ManagedResourceMode,
Type: "test_object",
Name: "a",
}.Instance(addrs.NoKey),
&states.ResourceInstanceObjectSrc{
Status: states.ObjectReady,
AttrsJSON: []byte(`{"id":"a_id"}`),
CreateBeforeDestroy: true,
},
Mildwonkey/tests (#24522) * terraform: add helper functions for creating test state testSetResourceInstanceCurrent and testSetResourceInstanceTainted are wrapper functions around states.Module.SetResourceInstanceCurrent() used to set a resource in state. They work with current, non-deposed resources with no dependencies. testSetResourceInstanceDeposed can be used to set a desosed resource in state. * terraform: update all tests to use modern providers and state
2020-04-01 12:13:40 -05:00
mustProviderConfig(`provider["registry.terraform.io/hashicorp/test"]`),
test for CBD instance being removed entirely Even though this is only the destroy half of CreateBeforeDestroy, the resource may still require the same destroy order.
2019-12-12 14:02:26 -06:00
)
root.SetResourceInstanceCurrent(
addrs.Resource{
Mode: addrs.ManagedResourceMode,
Type: "test_object",
Name: "b",
}.Instance(addrs.NoKey),
&states.ResourceInstanceObjectSrc{
Status: states.ObjectReady,
AttrsJSON: []byte(`{"id":"b_id","test_string":"a_id"}`),
use addrs.ConfigResource for dependency tracking We can't get module instances during transformation, so we need to reduce the Dependencies to using `addrs.ConfigResource` for now.
2020-03-23 14:26:18 -05:00
Dependencies: []addrs.ConfigResource{
addrs.ConfigResource{
test for CBD instance being removed entirely Even though this is only the destroy half of CreateBeforeDestroy, the resource may still require the same destroy order.
2019-12-12 14:02:26 -06:00
Resource: addrs.Resource{
Mode: addrs.ManagedResourceMode,
Type: "test_object",
Name: "a",
},
use addrs.ConfigResource for dependency tracking We can't get module instances during transformation, so we need to reduce the Dependencies to using `addrs.ConfigResource` for now.
2020-03-23 14:26:18 -05:00
Module: root.Addr.Module(),
test for CBD instance being removed entirely Even though this is only the destroy half of CreateBeforeDestroy, the resource may still require the same destroy order.
2019-12-12 14:02:26 -06:00
},
},
},
Mildwonkey/tests (#24522) * terraform: add helper functions for creating test state testSetResourceInstanceCurrent and testSetResourceInstanceTainted are wrapper functions around states.Module.SetResourceInstanceCurrent() used to set a resource in state. They work with current, non-deposed resources with no dependencies. testSetResourceInstanceDeposed can be used to set a desosed resource in state. * terraform: update all tests to use modern providers and state
2020-04-01 12:13:40 -05:00
mustProviderConfig(`provider["registry.terraform.io/hashicorp/test"]`),
test for CBD instance being removed entirely Even though this is only the destroy half of CreateBeforeDestroy, the resource may still require the same destroy order.
2019-12-12 14:02:26 -06:00
)
b := &ApplyGraphBuilder{
Config: testModule(t, "graph-builder-apply-orphan-update"),
Changes: changes,
Components: simpleMockComponentFactory(),
Schemas: schemas,
State: state,
}
g, err := b.Build(addrs.RootModuleInstance)
if err != nil {
t.Fatalf("err: %s", err)
}
expected := strings.TrimSpace(`
test_object.a (destroy)
test_object.b
test_object.b
`)
instanceGraph := filterInstances(g)
use Dependencies to connect creator and destroyer The DestroyEdgeTransformer cannot determine ordering from the graph when the destroyers are from orphaned resources, because there are no references to resolve. The new stored Dependencies provides what we need to connect the instances in this case. We also add the StateDependencies method directly in the GraphNodeResourceInstance interface, since all instances already implement this, and we don't need another optional interface to check. The old code in DestroyEdgeTransformer may no longer be needed in the long run, but that can be determined separately, since too many of the tests start with an incomplete state and rely on the Dependencies being determined from the configuration alone.
2019-10-30 14:59:34 -05:00
got := strings.TrimSpace(instanceGraph.String())
if got != expected {
t.Fatalf("expected:\n%s\ngot:\n%s", expected, got)
failing test for update from orphaned instance Updates resulting from orphaned instances should happen after the deletion of the instances.
2019-10-29 09:57:38 -05:00
}
}
NodeDestroyResource does not need a provider The resource cleanup node does not need a provider. We can't directly remove the ProvidedBy method, but this node only needs to be eval-able so we can remove all the NodeAbstractResource methods at once.
2019-12-16 16:45:34 -06:00
// The orphan clean up node should not be connected to a provider
func TestApplyGraphBuilder_orphanedWithProvider(t *testing.T) {
changes := &plans.Changes{
Resources: []*plans.ResourceInstanceChangeSrc{
{
Addr: mustResourceInstanceAddr("test_object.A"),
ChangeSrc: plans.ChangeSrc{
Action: plans.Delete,
},
},
},
}
state := states.NewState()
root := state.EnsureModule(addrs.RootModuleInstance)
root.SetResourceInstanceCurrent(
mustResourceInstanceAddr("test_object.A").Resource,
&states.ResourceInstanceObjectSrc{
Status: states.ObjectReady,
AttrsJSON: []byte(`{"id":"A"}`),
},
Mildwonkey/tests (#24522) * terraform: add helper functions for creating test state testSetResourceInstanceCurrent and testSetResourceInstanceTainted are wrapper functions around states.Module.SetResourceInstanceCurrent() used to set a resource in state. They work with current, non-deposed resources with no dependencies. testSetResourceInstanceDeposed can be used to set a desosed resource in state. * terraform: update all tests to use modern providers and state
2020-04-01 12:13:40 -05:00
mustProviderConfig(`provider["registry.terraform.io/hashicorp/test"].foo`),
NodeDestroyResource does not need a provider The resource cleanup node does not need a provider. We can't directly remove the ProvidedBy method, but this node only needs to be eval-able so we can remove all the NodeAbstractResource methods at once.
2019-12-16 16:45:34 -06:00
)
b := &ApplyGraphBuilder{
Config: testModule(t, "graph-builder-orphan-alias"),
Changes: changes,
Components: simpleMockComponentFactory(),
Schemas: simpleTestSchemas(),
State: state,
}
g, err := b.Build(addrs.RootModuleInstance)
if err != nil {
t.Fatal(err)
}
// The cleanup node has no state or config of its own, so would create a
// default provider which we don't want.
testGraphNotContains(t, g, "provider.test")
}
terraform: start apply-based graph builder, basic diff transform
2016-09-13 12:56:37 -05:00
const testApplyGraphBuilderStr = `
core: update test fixtures for new name of the "count boundary" vertex
2018-09-07 18:58:32 -05:00
meta.count-boundary (EachMode fixup)
fix new graph builder test output
2020-04-02 12:43:23 -05:00
module.child (close)
core: ApplyGraphBuilder tests to use the "test" mock provider These tests now need schema available to run properly, so rather than crafting a separate schema for each of these we'll just use the one created by simpleMockProvider, which contains a resource type called test_object that we'll now use as the basis for all of the tests here.
2018-05-10 17:38:58 -05:00
test_object.other
fix new graph builder test output
2020-04-02 12:43:23 -05:00
module.child (close)
module.child.test_object.other
update test strings Match the new names output by the expander nodes
2020-05-12 09:54:43 -05:00
module.child (expand)
core: ApplyGraphBuilder tests to use the "test" mock provider These tests now need schema available to run properly, so rather than crafting a separate schema for each of these we'll just use the one created by simpleMockProvider, which contains a resource type called test_object that we'll now use as the basis for all of the tests here.
2018-05-10 17:38:58 -05:00
module.child.test_object.create
update test strings Match the new names output by the expander nodes
2020-05-12 09:54:43 -05:00
module.child.test_object.create (expand)
module.child.test_object.create (expand)
module.child (expand)
Mildwonkey/tests (#24522) * terraform: add helper functions for creating test state testSetResourceInstanceCurrent and testSetResourceInstanceTainted are wrapper functions around states.Module.SetResourceInstanceCurrent() used to set a resource in state. They work with current, non-deposed resources with no dependencies. testSetResourceInstanceDeposed can be used to set a desosed resource in state. * terraform: update all tests to use modern providers and state
2020-04-01 12:13:40 -05:00
provider["registry.terraform.io/hashicorp/test"]
update tests to reflect correct provisioners We no longer create new provisioners for every module.
2019-08-21 18:32:14 -05:00
provisioner.test
core: ApplyGraphBuilder tests to use the "test" mock provider These tests now need schema available to run properly, so rather than crafting a separate schema for each of these we'll just use the one created by simpleMockProvider, which contains a resource type called test_object that we'll now use as the basis for all of the tests here.
2018-05-10 17:38:58 -05:00
module.child.test_object.other
module.child.test_object.create
update test strings Match the new names output by the expander nodes
2020-05-12 09:54:43 -05:00
module.child.test_object.other (expand)
module.child.test_object.other (expand)
module.child (expand)
Mildwonkey/tests (#24522) * terraform: add helper functions for creating test state testSetResourceInstanceCurrent and testSetResourceInstanceTainted are wrapper functions around states.Module.SetResourceInstanceCurrent() used to set a resource in state. They work with current, non-deposed resources with no dependencies. testSetResourceInstanceDeposed can be used to set a desosed resource in state. * terraform: update all tests to use modern providers and state
2020-04-01 12:13:40 -05:00
provider["registry.terraform.io/hashicorp/test"]
provider["registry.terraform.io/hashicorp/test"]
provider["registry.terraform.io/hashicorp/test"] (close)
core: ApplyGraphBuilder tests to use the "test" mock provider These tests now need schema available to run properly, so rather than crafting a separate schema for each of these we'll just use the one created by simpleMockProvider, which contains a resource type called test_object that we'll now use as the basis for all of the tests here.
2018-05-10 17:38:58 -05:00
module.child.test_object.other
test_object.other
update tests to reflect correct provisioners We no longer create new provisioners for every module.
2019-08-21 18:32:14 -05:00
provisioner.test
core: ApplyGraphBuilder tests to use the "test" mock provider These tests now need schema available to run properly, so rather than crafting a separate schema for each of these we'll just use the one created by simpleMockProvider, which contains a resource type called test_object that we'll now use as the basis for all of the tests here.
2018-05-10 17:38:58 -05:00
provisioner.test (close)
module.child.test_object.create
Add the close provider and provisioner transformers (#13102)
2017-04-12 16:25:15 -05:00
root
core: update test fixtures for new name of the "count boundary" vertex
2018-09-07 18:58:32 -05:00
meta.count-boundary (EachMode fixup)
Mildwonkey/tests (#24522) * terraform: add helper functions for creating test state testSetResourceInstanceCurrent and testSetResourceInstanceTainted are wrapper functions around states.Module.SetResourceInstanceCurrent() used to set a resource in state. They work with current, non-deposed resources with no dependencies. testSetResourceInstanceDeposed can be used to set a desosed resource in state. * terraform: update all tests to use modern providers and state
2020-04-01 12:13:40 -05:00
provider["registry.terraform.io/hashicorp/test"] (close)
core: ApplyGraphBuilder tests to use the "test" mock provider These tests now need schema available to run properly, so rather than crafting a separate schema for each of these we'll just use the one created by simpleMockProvider, which contains a resource type called test_object that we'll now use as the basis for all of the tests here.
2018-05-10 17:38:58 -05:00
provisioner.test (close)
test_object.create
update test strings Match the new names output by the expander nodes
2020-05-12 09:54:43 -05:00
test_object.create (expand)
test_object.create (expand)
Mildwonkey/tests (#24522) * terraform: add helper functions for creating test state testSetResourceInstanceCurrent and testSetResourceInstanceTainted are wrapper functions around states.Module.SetResourceInstanceCurrent() used to set a resource in state. They work with current, non-deposed resources with no dependencies. testSetResourceInstanceDeposed can be used to set a desosed resource in state. * terraform: update all tests to use modern providers and state
2020-04-01 12:13:40 -05:00
provider["registry.terraform.io/hashicorp/test"]
core: ApplyGraphBuilder tests to use the "test" mock provider These tests now need schema available to run properly, so rather than crafting a separate schema for each of these we'll just use the one created by simpleMockProvider, which contains a resource type called test_object that we'll now use as the basis for all of the tests here.
2018-05-10 17:38:58 -05:00
test_object.other
test_object.create
update test strings Match the new names output by the expander nodes
2020-05-12 09:54:43 -05:00
test_object.other (expand)
test_object.other (expand)
Mildwonkey/tests (#24522) * terraform: add helper functions for creating test state testSetResourceInstanceCurrent and testSetResourceInstanceTainted are wrapper functions around states.Module.SetResourceInstanceCurrent() used to set a resource in state. They work with current, non-deposed resources with no dependencies. testSetResourceInstanceDeposed can be used to set a desosed resource in state. * terraform: update all tests to use modern providers and state
2020-04-01 12:13:40 -05:00
provider["registry.terraform.io/hashicorp/test"]
terraform: start apply-based graph builder, basic diff transform
2016-09-13 12:56:37 -05:00
`
terraform: apply resource must depend on destroy deps Fixes #10440 This updates the behavior of "apply" resources to depend on the destroy versions of their dependencies. We make an exception to this behavior when the "apply" resource is CBD. This is odd and not 100% correct, but it mimics the behavior of the legacy graphs and avoids us having to do major core work to support the 100% correct solution. I'll explain this in examples... Given the following configuration: resource "null_resource" "a" { count = "${var.count}" } resource "null_resource" "b" { triggers { key = "${join(",", null_resource.a.*.id)}" } } Assume we've successfully created this configuration with count = 2. When going from count = 2 to count = 1, `null_resource.b` should wait for `null_resource.a.1` to destroy. If it doesn't, then it is a race: depending when we interpolate the `triggers.key` attribute of `null_resource.b`, we may get 1 value or 2. If `null_resource.a.1` is destroyed, we'll get 1. Otherwise, we'll get 2. This was the root cause of #10440 In the legacy graphs, `null_resource.b` would depend on the destruction of any `null_resource.a` (orphans, tainted, anything!). This would ensure proper ordering. We mimic that behavior here. The difference is CBD. If `null_resource.b` has CBD enabled, then the ordering **in the legacy graph** becomes: 1. null_resource.b (create) 2. null_resource.b (destroy) 3. null_resource.a (destroy) In this case, the update would always have 2 values for `triggers.key`, even though we were destroying a resource later! This scenario required two `terraform apply` operations. This is what the CBD check is for in this PR. We do this to mimic the behavior of the legacy graph. The correct solution to do one day is to allow splat references (`null_resource.a.*.id`) to happen in parallel and only read up to to the `count` amount in the state. This requires some fairly significant work close to the 0.8 release date, so we can defer this to later and adopt the 0.7.x behavior for now.
2016-12-04 01:44:09 -06:00
const testApplyGraphBuilderDestroyCountStr = `
core: update test fixtures for new name of the "count boundary" vertex
2018-09-07 18:58:32 -05:00
meta.count-boundary (EachMode fixup)
core: ApplyGraphBuilder tests to use the "test" mock provider These tests now need schema available to run properly, so rather than crafting a separate schema for each of these we'll just use the one created by simpleMockProvider, which contains a resource type called test_object that we'll now use as the basis for all of the tests here.
2018-05-10 17:38:58 -05:00
test_object.B
Mildwonkey/tests (#24522) * terraform: add helper functions for creating test state testSetResourceInstanceCurrent and testSetResourceInstanceTainted are wrapper functions around states.Module.SetResourceInstanceCurrent() used to set a resource in state. They work with current, non-deposed resources with no dependencies. testSetResourceInstanceDeposed can be used to set a desosed resource in state. * terraform: update all tests to use modern providers and state
2020-04-01 12:13:40 -05:00
provider["registry.terraform.io/hashicorp/test"]
provider["registry.terraform.io/hashicorp/test"] (close)
core: ApplyGraphBuilder tests to use the "test" mock provider These tests now need schema available to run properly, so rather than crafting a separate schema for each of these we'll just use the one created by simpleMockProvider, which contains a resource type called test_object that we'll now use as the basis for all of the tests here.
2018-05-10 17:38:58 -05:00
test_object.B
Add the close provider and provisioner transformers (#13102)
2017-04-12 16:25:15 -05:00
root
core: update test fixtures for new name of the "count boundary" vertex
2018-09-07 18:58:32 -05:00
meta.count-boundary (EachMode fixup)
Mildwonkey/tests (#24522) * terraform: add helper functions for creating test state testSetResourceInstanceCurrent and testSetResourceInstanceTainted are wrapper functions around states.Module.SetResourceInstanceCurrent() used to set a resource in state. They work with current, non-deposed resources with no dependencies. testSetResourceInstanceDeposed can be used to set a desosed resource in state. * terraform: update all tests to use modern providers and state
2020-04-01 12:13:40 -05:00
provider["registry.terraform.io/hashicorp/test"] (close)
update test strings Match the new names output by the expander nodes
2020-05-12 09:54:43 -05:00
test_object.A (expand)
Mildwonkey/tests (#24522) * terraform: add helper functions for creating test state testSetResourceInstanceCurrent and testSetResourceInstanceTainted are wrapper functions around states.Module.SetResourceInstanceCurrent() used to set a resource in state. They work with current, non-deposed resources with no dependencies. testSetResourceInstanceDeposed can be used to set a desosed resource in state. * terraform: update all tests to use modern providers and state
2020-04-01 12:13:40 -05:00
provider["registry.terraform.io/hashicorp/test"]
finish graph builder test updates
2018-09-25 09:42:44 -05:00
test_object.A[1] (destroy)
Mildwonkey/tests (#24522) * terraform: add helper functions for creating test state testSetResourceInstanceCurrent and testSetResourceInstanceTainted are wrapper functions around states.Module.SetResourceInstanceCurrent() used to set a resource in state. They work with current, non-deposed resources with no dependencies. testSetResourceInstanceDeposed can be used to set a desosed resource in state. * terraform: update all tests to use modern providers and state
2020-04-01 12:13:40 -05:00
provider["registry.terraform.io/hashicorp/test"]
core: ApplyGraphBuilder tests to use the "test" mock provider These tests now need schema available to run properly, so rather than crafting a separate schema for each of these we'll just use the one created by simpleMockProvider, which contains a resource type called test_object that we'll now use as the basis for all of the tests here.
2018-05-10 17:38:58 -05:00
test_object.B
update test strings Match the new names output by the expander nodes
2020-05-12 09:54:43 -05:00
test_object.A (expand)
core: ApplyGraphBuilder tests to use the "test" mock provider These tests now need schema available to run properly, so rather than crafting a separate schema for each of these we'll just use the one created by simpleMockProvider, which contains a resource type called test_object that we'll now use as the basis for all of the tests here.
2018-05-10 17:38:58 -05:00
test_object.A[1] (destroy)
update test strings Match the new names output by the expander nodes
2020-05-12 09:54:43 -05:00
test_object.B (expand)
test_object.B (expand)
Mildwonkey/tests (#24522) * terraform: add helper functions for creating test state testSetResourceInstanceCurrent and testSetResourceInstanceTainted are wrapper functions around states.Module.SetResourceInstanceCurrent() used to set a resource in state. They work with current, non-deposed resources with no dependencies. testSetResourceInstanceDeposed can be used to set a desosed resource in state. * terraform: update all tests to use modern providers and state
2020-04-01 12:13:40 -05:00
provider["registry.terraform.io/hashicorp/test"]
terraform: apply resource must depend on destroy deps Fixes #10440 This updates the behavior of "apply" resources to depend on the destroy versions of their dependencies. We make an exception to this behavior when the "apply" resource is CBD. This is odd and not 100% correct, but it mimics the behavior of the legacy graphs and avoids us having to do major core work to support the 100% correct solution. I'll explain this in examples... Given the following configuration: resource "null_resource" "a" { count = "${var.count}" } resource "null_resource" "b" { triggers { key = "${join(",", null_resource.a.*.id)}" } } Assume we've successfully created this configuration with count = 2. When going from count = 2 to count = 1, `null_resource.b` should wait for `null_resource.a.1` to destroy. If it doesn't, then it is a race: depending when we interpolate the `triggers.key` attribute of `null_resource.b`, we may get 1 value or 2. If `null_resource.a.1` is destroyed, we'll get 1. Otherwise, we'll get 2. This was the root cause of #10440 In the legacy graphs, `null_resource.b` would depend on the destruction of any `null_resource.a` (orphans, tainted, anything!). This would ensure proper ordering. We mimic that behavior here. The difference is CBD. If `null_resource.b` has CBD enabled, then the ordering **in the legacy graph** becomes: 1. null_resource.b (create) 2. null_resource.b (destroy) 3. null_resource.a (destroy) In this case, the update would always have 2 values for `triggers.key`, even though we were destroying a resource later! This scenario required two `terraform apply` operations. This is what the CBD check is for in this PR. We do this to mimic the behavior of the legacy graph. The correct solution to do one day is to allow splat references (`null_resource.a.*.id`) to happen in parallel and only read up to to the `count` amount in the state. This requires some fairly significant work close to the 0.8 release date, so we can defer this to later and adopt the 0.7.x behavior for now.
2016-12-04 01:44:09 -06:00
`
Reference in New Issue Copy Permalink