IntenseWebs/opentofu
3
0
Fork 0
mirror of https://github.com/opentofu/opentofu.git synced 2025-01-15 19:22:46 -06:00
Code Issues Packages Projects Releases Wiki Activity
05e85885f9
opentofu/terraform/graph_builder_apply_test.go

583 lines
13 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 (
"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"
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) {
diff := &Diff{
Modules: []*ModuleDiff{
&ModuleDiff{
Path: []string{"root"},
Resources: map[string]*InstanceDiff{
// Verify noop doesn't show up in graph
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.noop": &InstanceDiff{},
terraform: start apply-based graph builder, basic diff transform
2016-09-13 12:56:37 -05:00
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.create": &InstanceDiff{
terraform: start apply-based graph builder, basic diff transform
2016-09-13 12:56:37 -05:00
Attributes: map[string]*ResourceAttrDiff{
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_string": &ResourceAttrDiff{
terraform: start apply-based graph builder, basic diff transform
2016-09-13 12:56:37 -05:00
Old: "",
New: "foo",
},
},
},
terraform: ReferenceTransform to connect references
2016-09-15 20:30:11 -05:00
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": &InstanceDiff{
terraform: ReferenceTransform to connect references
2016-09-15 20:30:11 -05:00
Attributes: map[string]*ResourceAttrDiff{
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_string": &ResourceAttrDiff{
terraform: ReferenceTransform to connect references
2016-09-15 20:30:11 -05:00
Old: "",
New: "foo",
},
},
},
terraform: start apply-based graph builder, basic diff transform
2016-09-13 12:56:37 -05:00
},
},
terraform: ParentProviderTransform to connect parent providers
2016-09-14 16:43:14 -05:00
&ModuleDiff{
Path: []string{"root", "child"},
Resources: map[string]*InstanceDiff{
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.create": &InstanceDiff{
terraform: ParentProviderTransform to connect parent providers
2016-09-14 16:43:14 -05:00
Attributes: map[string]*ResourceAttrDiff{
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_string": &ResourceAttrDiff{
terraform: ParentProviderTransform to connect parent providers
2016-09-14 16:43:14 -05:00
Old: "",
New: "foo",
},
},
},
terraform: test for referencetransform for modules
2016-09-15 20:31:13 -05:00
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": &InstanceDiff{
terraform: test for referencetransform for modules
2016-09-15 20:31:13 -05:00
Attributes: map[string]*ResourceAttrDiff{
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_string": &ResourceAttrDiff{
terraform: test for referencetransform for modules
2016-09-15 20:31:13 -05:00
Old: "",
New: "foo",
},
},
},
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{
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-basic"),
Diff: diff,
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: cbd works!
2016-09-22 13:03:03 -05:00
DisableReduce: true,
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())
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) {
diff := &Diff{
Modules: []*ModuleDiff{
&ModuleDiff{
Path: []string{"root"},
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
Resources: map[string]*InstanceDiff{"test_object.A": &InstanceDiff{Destroy: true,
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
Attributes: map[string]*ResourceAttrDiff{
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_string": &ResourceAttrDiff{
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
Old: "",
New: "foo",
RequiresNew: true,
terraform: CBD destroy nodes should not advertise themselves as normal
2017-02-07 13:49:50 -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
},
terraform: CBD destroy nodes should not advertise themselves as normal
2017-02-07 13:49:50 -06:00
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": &InstanceDiff{
terraform: CBD destroy nodes should not advertise themselves as normal
2017-02-07 13:49:50 -06:00
Attributes: map[string]*ResourceAttrDiff{
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_string": &ResourceAttrDiff{
terraform: CBD destroy nodes should not advertise themselves as normal
2017-02-07 13:49:50 -06:00
Old: "",
New: "foo",
},
},
},
},
},
},
}
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-dep-cbd"),
Diff: diff,
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: CBD destroy nodes should not advertise themselves as normal
2017-02-07 13:49:50 -06:00
DisableReduce: true,
}
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)
}
t.Logf("Graph: %s", g.String())
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
}
// 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",
"test_object.A (destroy)")
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",
"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",
"test_object.A (destroy)")
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) {
diff := &Diff{
Modules: []*ModuleDiff{
&ModuleDiff{
Path: []string{"root"},
Resources: map[string]*InstanceDiff{
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": &InstanceDiff{
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
Destroy: true,
Attributes: map[string]*ResourceAttrDiff{
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_string": &ResourceAttrDiff{
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
Old: "",
New: "foo",
},
},
},
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": &InstanceDiff{
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
Destroy: true,
Attributes: map[string]*ResourceAttrDiff{
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_string": &ResourceAttrDiff{
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
Old: "",
New: "foo",
},
},
},
},
},
},
}
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-double-cbd"),
Diff: diff,
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: 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
DisableReduce: true,
}
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
}
actual := strings.TrimSpace(g.String())
expected := strings.TrimSpace(testApplyGraphBuilderDoubleCBDStr)
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: 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) {
diff := &Diff{
Modules: []*ModuleDiff{
&ModuleDiff{
Path: []string{"root", "child"},
Resources: map[string]*InstanceDiff{
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": &InstanceDiff{
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
Destroy: true,
},
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": &InstanceDiff{
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
Destroy: true,
},
},
},
},
}
state := &State{
Modules: []*ModuleState{
&ModuleState{
Path: []string{"root", "child"},
Resources: map[string]*ResourceState{
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": &ResourceState{
Type: "test_object",
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
Primary: &InstanceState{
ID: "foo",
Attributes: map[string]string{},
},
},
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": &ResourceState{
Type: "test_object",
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
Primary: &InstanceState{
ID: "bar",
Attributes: map[string]string{},
},
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
Dependencies: []string{"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
},
},
},
},
}
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, "empty"),
Diff: diff,
State: state,
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: 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
DisableReduce: true,
}
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: 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
if err != nil {
t.Fatalf("err: %s", err)
}
t.Logf("Graph: %s", g.String())
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) {
diff := &Diff{
Modules: []*ModuleDiff{
&ModuleDiff{
Path: []string{"root"},
Resources: map[string]*InstanceDiff{
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": &InstanceDiff{
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
Destroy: true,
},
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": &InstanceDiff{
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
Attributes: map[string]*ResourceAttrDiff{
"name": &ResourceAttrDiff{
Old: "",
New: "foo",
},
},
},
},
},
},
}
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-count"),
Diff: diff,
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: 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
DisableReduce: true,
}
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) {
diff := &Diff{
Modules: []*ModuleDiff{
&ModuleDiff{
Path: []string{"root", "A"},
Resources: map[string]*InstanceDiff{
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.foo": &InstanceDiff{
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
Destroy: true,
},
},
},
&ModuleDiff{
Path: []string{"root", "B"},
Resources: map[string]*InstanceDiff{
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.foo": &InstanceDiff{
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
Destroy: true,
},
},
},
},
}
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"),
Diff: diff,
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: 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) {
diff := &Diff{
Modules: []*ModuleDiff{
&ModuleDiff{
Path: []string{"root"},
Resources: map[string]*InstanceDiff{
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.foo": &InstanceDiff{
terraform: run destroy provisioners on destroy
2017-01-20 20:07:51 -06:00
Attributes: map[string]*ResourceAttrDiff{
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_string": &ResourceAttrDiff{
terraform: run destroy provisioners on destroy
2017-01-20 20:07:51 -06:00
Old: "",
New: "foo",
},
},
},
},
},
},
}
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"),
Diff: diff,
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) {
diff := &Diff{
Modules: []*ModuleDiff{
&ModuleDiff{
Path: []string{"root"},
Resources: map[string]*InstanceDiff{
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.foo": &InstanceDiff{
terraform: run destroy provisioners on destroy
2017-01-20 20:07:51 -06:00
Destroy: true,
},
},
},
},
}
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
Destroy: true,
Config: testModule(t, "graph-builder-apply-provisioner"),
Diff: diff,
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) {
diff := &Diff{
Modules: []*ModuleDiff{
&ModuleDiff{
Path: []string{"root"},
Resources: map[string]*InstanceDiff{
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.foo": &InstanceDiff{
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
Attributes: map[string]*ResourceAttrDiff{
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_string": &ResourceAttrDiff{
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
Old: "",
New: "foo",
},
},
},
},
},
&ModuleDiff{
Path: []string{"root", "child2"},
Resources: map[string]*InstanceDiff{
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.foo": &InstanceDiff{
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
Attributes: map[string]*ResourceAttrDiff{
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_string": &ResourceAttrDiff{
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
Old: "",
New: "foo",
},
},
},
},
},
},
}
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"),
Diff: diff,
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")
}
terraform: start apply-based graph builder, basic diff transform
2016-09-13 12:56:37 -05:00
const testApplyGraphBuilderStr = `
terraform: cbd works!
2016-09-22 13:03:03 -05:00
meta.count-boundary (count boundary 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
module.child.provisioner.test
module.child.test_object.create
module.child.test_object.other
provider.test
test_object.create
test_object.other
module.child.provisioner.test
module.child.test_object.create
module.child.provisioner.test
provider.test
module.child.test_object.other
module.child.test_object.create
provider.test
provider.test
provider.test (close)
module.child.test_object.create
module.child.test_object.other
provider.test
test_object.create
test_object.other
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
meta.count-boundary (count boundary 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
provider.test (close)
provisioner.test (close)
test_object.create
provider.test
test_object.other
provider.test
test_object.create
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 testApplyGraphBuilderDoubleCBDStr = `
meta.count-boundary (count boundary 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
provider.test
test_object.A
test_object.A (destroy)
test_object.B
test_object.B (destroy)
provider.test
provider.test (close)
provider.test
test_object.A
test_object.A (destroy)
test_object.B
test_object.B (destroy)
Add the close provider and provisioner transformers (#13102)
2017-04-12 16:25:15 -05:00
root
meta.count-boundary (count boundary 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
provider.test (close)
test_object.A
provider.test
test_object.A (destroy)
provider.test
test_object.A
test_object.B
test_object.B (destroy)
test_object.B
provider.test
test_object.A
test_object.B (destroy)
provider.test
test_object.B
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 = `
meta.count-boundary (count boundary 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
provider.test
test_object.A[1] (destroy)
test_object.B
provider.test
provider.test (close)
provider.test
test_object.A[1] (destroy)
test_object.B
Add the close provider and provisioner transformers (#13102)
2017-04-12 16:25:15 -05:00
root
meta.count-boundary (count boundary 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
provider.test (close)
test_object.A[1] (destroy)
provider.test
test_object.B
provider.test
test_object.A[1] (destroy)
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