resilien
/
terraform
2
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
terraform/internal/terraform/node_resource_plan.go

400 lines
13 KiB
Go
Raw Normal View History

terraform: begin NodePlannableResource
2016-11-06 08:00:05 +01:00
package terraform
terraform: expand count in plan
2016-11-06 19:15:09 +01:00
import (
core: -replace to emit only one warning for incomplete address If the user gives an index-less address for a resource that expects instance keys then previously we would've emitted one error per declared instance of the resource, which is overwhelming and not especially helpful. Instead, we'll deal with that check prior to expanding resources into resource instances, and thus we can report a single error which talks about all of the instances at once. This does unfortunately come at the expense of splitting the logic for dealing with the "force replace" addresses into two places, which will likely make later maintenance harder. In an attempt to mitigate that, I've included a comment in each place that mentions the other place, which hopefully future maintainers will keep up-to-date if that situation changes.
2021-05-01 01:55:53 +02:00
"fmt"
make NodePlannableResource eval-able Eval a NodePlannableResource before expanding it, to ensure that it can be referenced even if the count is 0.
2018-09-20 03:30:16 +02:00
"log"
core: -replace to emit only one warning for incomplete address If the user gives an index-less address for a resource that expects instance keys then previously we would've emitted one error per declared instance of the resource, which is overwhelming and not especially helpful. Instead, we'll deal with that check prior to expanding resources into resource instances, and thus we can report a single error which talks about all of the instances at once. This does unfortunately come at the expense of splitting the logic for dealing with the "force replace" addresses into two places, which will likely make later maintenance harder. In an attempt to mitigate that, I've included a comment in each place that mentions the other place, which hopefully future maintainers will keep up-to-date if that situation changes.
2021-05-01 01:55:53 +02:00
"strings"
make NodePlannableResource eval-able Eval a NodePlannableResource before expanding it, to ensure that it can be referenced even if the count is 0.
2018-09-20 03:30:16 +02:00
Move addrs/ to internal/addrs/ This is part of a general effort to move all of Terraform's non-library package surface under internal in order to reinforce that these are for internal use within Terraform only. If you were previously importing packages under this prefix into an external codebase, you could pin to an earlier release tag as an interim solution until you've make a plan to achieve the same functionality some other way.
2021-05-17 21:00:50 +02:00
"github.com/hashicorp/terraform/internal/addrs"
Move dag/ to internal/dag/ This is part of a general effort to move all of Terraform's non-library package surface under internal in order to reinforce that these are for internal use within Terraform only. If you were previously importing packages under this prefix into an external codebase, you could pin to an earlier release tag as an interim solution until you've make a plan to achieve the same functionality some other way.
2021-05-17 18:30:37 +02:00
"github.com/hashicorp/terraform/internal/dag"
Move states/ to internal/states/ This is part of a general effort to move all of Terraform's non-library package surface under internal in order to reinforce that these are for internal use within Terraform only. If you were previously importing packages under this prefix into an external codebase, you could pin to an earlier release tag as an interim solution until you've make a plan to achieve the same functionality some other way.
2021-05-17 21:43:35 +02:00
"github.com/hashicorp/terraform/internal/states"
Move tfdiags/ to internal/tfdiags/ This is part of a general effort to move all of Terraform's non-library package surface under internal in order to reinforce that these are for internal use within Terraform only. If you were previously importing packages under this prefix into an external codebase, you could pin to an earlier release tag as an interim solution until you've make a plan to achieve the same functionality some other way.
2021-05-17 19:11:06 +02:00
"github.com/hashicorp/terraform/internal/tfdiags"
terraform: expand count in plan
2016-11-06 19:15:09 +01:00
)
expand planned resources While the Expander itself now handles the recursive expansion of modules, Resources themselves still need to be expanded twice, because the evaluation of the Resource, which entails evaluating the for_each or count expressions, is separate from the ResourceInstance expansion. Add a nodeExpandPlannableResource to do handle this expansion to allow all NodePlannableResources to call EvalWriteResourceState with an absolute address.
2020-03-20 20:19:01 +01:00
// nodeExpandPlannableResource handles the first layer of resource
// expansion. We need this extra layer so DynamicExpand is called twice for
// the resource, the first to expand the Resource for each module instance, and
comment updates
2020-03-25 20:53:54 +01:00
// the second to expand each ResourceInstance for the expanded Resources.
expand planned resources While the Expander itself now handles the recursive expansion of modules, Resources themselves still need to be expanded twice, because the evaluation of the Resource, which entails evaluating the for_each or count expressions, is separate from the ResourceInstance expansion. Add a nodeExpandPlannableResource to do handle this expansion to allow all NodePlannableResources to call EvalWriteResourceState with an absolute address.
2020-03-20 20:19:01 +01:00
type nodeExpandPlannableResource struct {
*NodeAbstractResource
// ForceCreateBeforeDestroy might be set via our GraphNodeDestroyerCBD
// during graph construction, if dependencies require us to force this
// on regardless of what the configuration says.
ForceCreateBeforeDestroy *bool
attach dependencies during plan This was previously done during refresh alone, now we need to insert these during the refresh portion of plan.
2020-09-21 21:53:53 +02:00
thread skipContext through to the instance node
2020-09-23 17:05:09 +02:00
// skipRefresh indicates that we should skip refreshing individual instances
skipRefresh bool
core: Minimal initial implementation of "refresh only" planning mode This only includes the core mechanisms to make it work. There's not yet any way to turn this mode on as an end-user, because we have to do some more work at the UI layer to present this well before we could include it as an end-user-visible feature in a release. At the lowest level of abstraction inside the graph nodes themselves, this effectively mirrors the existing option to disable refreshing with a new option to disable change-planning, so that either "half" of the process can be disabled. As far as the nodes are concerned it would be possible in principle to disable _both_, but the higher-level representation of these modes prevents that combination from reaching Terraform Core in practice, because we block using -refresh-only and -refresh=false at the same time.
2021-04-06 02:05:57 +02:00
// skipPlanChanges indicates we should skip trying to plan change actions
// for any instances.
skipPlanChanges bool
core: Minimal initial implementation of -replace=... option This only includes the internal mechanisms to make it work, and not any of the necessary UI changes to "terraform plan" and "terraform apply" to activate it yet. The force-replace options are ultimately handled inside the NodeAbstractResourceInstance.plan method, at the same place we handle the similar situation of the provider indicating that replacement is needed, and so the rest of the changes here are just to propagate the settings through all of the layers in order to reach that point.
2021-04-07 02:37:38 +02:00
// forceReplace are resource instance addresses where the user wants to
// force generating a replace action. This set isn't pre-filtered, so
// it might contain addresses that have nothing to do with the resource
// that this node represents, which the node itself must therefore ignore.
forceReplace []addrs.AbsResourceInstance
attach dependencies during plan This was previously done during refresh alone, now we need to insert these during the refresh portion of plan.
2020-09-21 21:53:53 +02:00
// We attach dependencies to the Resource during refresh, since the
// instances are instantiated during DynamicExpand.
dependencies []addrs.ConfigResource
expand planned resources While the Expander itself now handles the recursive expansion of modules, Resources themselves still need to be expanded twice, because the evaluation of the Resource, which entails evaluating the for_each or count expressions, is separate from the ResourceInstance expansion. Add a nodeExpandPlannableResource to do handle this expansion to allow all NodePlannableResources to call EvalWriteResourceState with an absolute address.
2020-03-20 20:19:01 +01:00
}
var (
_ GraphNodeDestroyerCBD = (*nodeExpandPlannableResource)(nil)
_ GraphNodeDynamicExpandable = (*nodeExpandPlannableResource)(nil)
_ GraphNodeReferenceable = (*nodeExpandPlannableResource)(nil)
_ GraphNodeReferencer = (*nodeExpandPlannableResource)(nil)
_ GraphNodeConfigResource = (*nodeExpandPlannableResource)(nil)
_ GraphNodeAttachResourceConfig = (*nodeExpandPlannableResource)(nil)
attach dependencies during plan This was previously done during refresh alone, now we need to insert these during the refresh portion of plan.
2020-09-21 21:53:53 +02:00
_ GraphNodeAttachDependencies = (*nodeExpandPlannableResource)(nil)
ignore module indices in pre-expansion targeting The TargetsTransformer ignored resource indices before expansion could happen, but was not handling module indices. Ensure that we collapse all pre-expansion addresses to "configuration" addresses, with no module or resource keys.
2020-06-10 21:39:29 +02:00
_ GraphNodeTargetable = (*nodeExpandPlannableResource)(nil)
expand planned resources While the Expander itself now handles the recursive expansion of modules, Resources themselves still need to be expanded twice, because the evaluation of the Resource, which entails evaluating the for_each or count expressions, is separate from the ResourceInstance expansion. Add a nodeExpandPlannableResource to do handle this expansion to allow all NodePlannableResources to call EvalWriteResourceState with an absolute address.
2020-03-20 20:19:01 +01:00
)
remove "prepare state" from expanders That name tag was left in only to reduce the diff when during implementation. Fix the naming now for these nodes so it is correct, and prevent any possible name collision between types.
2020-05-12 16:28:33 +02:00
func (n *nodeExpandPlannableResource) Name() string {
return n.NodeAbstractResource.Name() + " (expand)"
}
attach dependencies during plan This was previously done during refresh alone, now we need to insert these during the refresh portion of plan.
2020-09-21 21:53:53 +02:00
// GraphNodeAttachDependencies
func (n *nodeExpandPlannableResource) AttachDependencies(deps []addrs.ConfigResource) {
n.dependencies = deps
}
expand planned resources While the Expander itself now handles the recursive expansion of modules, Resources themselves still need to be expanded twice, because the evaluation of the Resource, which entails evaluating the for_each or count expressions, is separate from the ResourceInstance expansion. Add a nodeExpandPlannableResource to do handle this expansion to allow all NodePlannableResources to call EvalWriteResourceState with an absolute address.
2020-03-20 20:19:01 +01:00
// GraphNodeDestroyerCBD
func (n *nodeExpandPlannableResource) CreateBeforeDestroy() bool {
if n.ForceCreateBeforeDestroy != nil {
return *n.ForceCreateBeforeDestroy
}
// If we have no config, we just assume no
if n.Config == nil || n.Config.Managed == nil {
return false
}
return n.Config.Managed.CreateBeforeDestroy
}
// GraphNodeDestroyerCBD
func (n *nodeExpandPlannableResource) ModifyCreateBeforeDestroy(v bool) error {
n.ForceCreateBeforeDestroy = &v
return nil
}
func (n *nodeExpandPlannableResource) DynamicExpand(ctx EvalContext) (*Graph, error) {
var g Graph
expander := ctx.InstanceExpander()
expansion resource and instance orphans When a module instances is removed, we need to add both the instance and resource deletion nodes from that module.
2020-03-27 22:16:08 +01:00
moduleInstances := expander.ExpandModule(n.Addr.Module)
// Add the current expanded resource to the graph
for _, module := range moduleInstances {
resAddr := n.Addr.Resource.Absolute(module)
expand planned resources While the Expander itself now handles the recursive expansion of modules, Resources themselves still need to be expanded twice, because the evaluation of the Resource, which entails evaluating the for_each or count expressions, is separate from the ResourceInstance expansion. Add a nodeExpandPlannableResource to do handle this expansion to allow all NodePlannableResources to call EvalWriteResourceState with an absolute address.
2020-03-20 20:19:01 +01:00
g.Add(&NodePlannableResource{
NodeAbstractResource: n.NodeAbstractResource,
expansion resource and instance orphans When a module instances is removed, we need to add both the instance and resource deletion nodes from that module.
2020-03-27 22:16:08 +01:00
Addr: resAddr,
expand planned resources While the Expander itself now handles the recursive expansion of modules, Resources themselves still need to be expanded twice, because the evaluation of the Resource, which entails evaluating the for_each or count expressions, is separate from the ResourceInstance expansion. Add a nodeExpandPlannableResource to do handle this expansion to allow all NodePlannableResources to call EvalWriteResourceState with an absolute address.
2020-03-20 20:19:01 +01:00
ForceCreateBeforeDestroy: n.ForceCreateBeforeDestroy,
attach dependencies during plan This was previously done during refresh alone, now we need to insert these during the refresh portion of plan.
2020-09-21 21:53:53 +02:00
dependencies: n.dependencies,
thread skipContext through to the instance node
2020-09-23 17:05:09 +02:00
skipRefresh: n.skipRefresh,
core: Minimal initial implementation of "refresh only" planning mode This only includes the core mechanisms to make it work. There's not yet any way to turn this mode on as an end-user, because we have to do some more work at the UI layer to present this well before we could include it as an end-user-visible feature in a release. At the lowest level of abstraction inside the graph nodes themselves, this effectively mirrors the existing option to disable refreshing with a new option to disable change-planning, so that either "half" of the process can be disabled. As far as the nodes are concerned it would be possible in principle to disable _both_, but the higher-level representation of these modes prevents that combination from reaching Terraform Core in practice, because we block using -refresh-only and -refresh=false at the same time.
2021-04-06 02:05:57 +02:00
skipPlanChanges: n.skipPlanChanges,
core: Minimal initial implementation of -replace=... option This only includes the internal mechanisms to make it work, and not any of the necessary UI changes to "terraform plan" and "terraform apply" to activate it yet. The force-replace options are ultimately handled inside the NodeAbstractResourceInstance.plan method, at the same place we handle the similar situation of the provider indicating that replacement is needed, and so the rest of the changes here are just to propagate the settings through all of the layers in order to reach that point.
2021-04-07 02:37:38 +02:00
forceReplace: n.forceReplace,
expand planned resources While the Expander itself now handles the recursive expansion of modules, Resources themselves still need to be expanded twice, because the evaluation of the Resource, which entails evaluating the for_each or count expressions, is separate from the ResourceInstance expansion. Add a nodeExpandPlannableResource to do handle this expansion to allow all NodePlannableResources to call EvalWriteResourceState with an absolute address.
2020-03-20 20:19:01 +01:00
})
}
expansion resource and instance orphans When a module instances is removed, we need to add both the instance and resource deletion nodes from that module.
2020-03-27 22:16:08 +01:00
// Lock the state while we inspect it
state := ctx.State().Lock()
defer ctx.State().Unlock()
var orphans []*states.Resource
for _, res := range state.Resources(n.Addr) {
found := false
for _, m := range moduleInstances {
if m.Equal(res.Addr.Module) {
found = true
break
}
}
// Address form state was not found in the current config
if !found {
orphans = append(orphans, res)
}
}
// The concrete resource factory we'll use for orphans
concreteResourceOrphan := func(a *NodeAbstractResourceInstance) *NodePlannableResourceInstanceOrphan {
// Add the config and state since we don't do that via transforms
a.Config = n.Config
a.ResolvedProvider = n.ResolvedProvider
a.Schema = n.Schema
a.ProvisionerSchemas = n.ProvisionerSchemas
a.ProviderMetas = n.ProviderMetas
attach dependencies during plan This was previously done during refresh alone, now we need to insert these during the refresh portion of plan.
2020-09-21 21:53:53 +02:00
a.Dependencies = n.dependencies
expansion resource and instance orphans When a module instances is removed, we need to add both the instance and resource deletion nodes from that module.
2020-03-27 22:16:08 +01:00
return &NodePlannableResourceInstanceOrphan{
NodeAbstractResourceInstance: a,
core: Fix refresh-only interaction with orphans When planning in refresh-only mode, we must not remove orphaned resources due to changed count or for_each values from the planned state. This was previously happening because we failed to pass through the plan's skip-plan-changes flag to the instance orphan node.
2021-09-23 22:38:08 +02:00
skipRefresh: n.skipRefresh,
skipPlanChanges: n.skipPlanChanges,
expansion resource and instance orphans When a module instances is removed, we need to add both the instance and resource deletion nodes from that module.
2020-03-27 22:16:08 +01:00
}
}
for _, res := range orphans {
for key := range res.Instances {
addr := res.Addr.Instance(key)
abs := NewNodeAbstractResourceInstance(addr)
abs.AttachResourceState(res)
n := concreteResourceOrphan(abs)
g.Add(n)
}
}
expand planned resources While the Expander itself now handles the recursive expansion of modules, Resources themselves still need to be expanded twice, because the evaluation of the Resource, which entails evaluating the for_each or count expressions, is separate from the ResourceInstance expansion. Add a nodeExpandPlannableResource to do handle this expansion to allow all NodePlannableResources to call EvalWriteResourceState with an absolute address.
2020-03-20 20:19:01 +01:00
return &g, nil
}
terraform: begin NodePlannableResource
2016-11-06 08:00:05 +01:00
// NodePlannableResource represents a resource that is "plannable":
// it is ready to be planned in order to create a diff.
type NodePlannableResource struct {
terraform: ugly huge change to weave in new HCL2-oriented types Due to how deeply the configuration types go into Terraform Core, there isn't a great way to switch out to HCL2 gradually. As a consequence, this huge commit gets us from the old state to a _compilable_ new state, but does not yet attempt to fix any tests and has a number of known missing parts and bugs. We will continue to iterate on this in forthcoming commits, heading back towards passing tests and making Terraform fully-functional again. The three main goals here are: - Use the configuration models from the "configs" package instead of the older models in the "config" package, which is now deprecated and preserved only to help us write our migration tool. - Do expression inspection and evaluation using the functionality of the new "lang" package, instead of the Interpolator type and related functionality in the main "terraform" package. - Represent addresses of various objects using types in the addrs package, rather than hand-constructed strings. This is not critical to support the above, but was a big help during the implementation of these other points since it made it much more explicit what kind of address is expected in each context. Since our new packages are built to accommodate some future planned features that are not yet implemented (e.g. the "for_each" argument on resources, "count"/"for_each" on modules), and since there's still a fair amount of functionality still using old-style APIs, there is a moderate amount of shimming here to connect new assumptions with old, hopefully in a way that makes it easier to find and eliminate these shims later. I apologize in advance to the person who inevitably just found this huge commit while spelunking through the commit history.
2018-04-30 19:33:53 +02:00
*NodeAbstractResource
core: Handle forced-create_before_destroy during the plan walk Previously we used a single plan action "Replace" to represent both the destroy-before-create and the create-before-destroy variants of replacing. However, this forces the apply graph builder to jump through a lot of hoops to figure out which nodes need it forced on and rebuild parts of the graph to represent that. If we instead decide between these two cases at plan time, the actual determination of it is more straightforward because each resource is represented by only one node in the plan graph, and then we can ensure we put the right nodes in the graph during DiffTransformer and thus avoid the logic for dealing with deposed instances being spread across various different transformers and node types. As a nice side-effect, this also allows us to show the difference between destroy-then-create and create-then-destroy in the rendered diff in the CLI, although this change doesn't fully implement that yet.
2018-09-22 02:08:52 +02:00
expand planned resources While the Expander itself now handles the recursive expansion of modules, Resources themselves still need to be expanded twice, because the evaluation of the Resource, which entails evaluating the for_each or count expressions, is separate from the ResourceInstance expansion. Add a nodeExpandPlannableResource to do handle this expansion to allow all NodePlannableResources to call EvalWriteResourceState with an absolute address.
2020-03-20 20:19:01 +01:00
Addr addrs.AbsResource
core: Handle forced-create_before_destroy during the plan walk Previously we used a single plan action "Replace" to represent both the destroy-before-create and the create-before-destroy variants of replacing. However, this forces the apply graph builder to jump through a lot of hoops to figure out which nodes need it forced on and rebuild parts of the graph to represent that. If we instead decide between these two cases at plan time, the actual determination of it is more straightforward because each resource is represented by only one node in the plan graph, and then we can ensure we put the right nodes in the graph during DiffTransformer and thus avoid the logic for dealing with deposed instances being spread across various different transformers and node types. As a nice side-effect, this also allows us to show the difference between destroy-then-create and create-then-destroy in the rendered diff in the CLI, although this change doesn't fully implement that yet.
2018-09-22 02:08:52 +02:00
// ForceCreateBeforeDestroy might be set via our GraphNodeDestroyerCBD
// during graph construction, if dependencies require us to force this
// on regardless of what the configuration says.
ForceCreateBeforeDestroy *bool
attach dependencies during plan This was previously done during refresh alone, now we need to insert these during the refresh portion of plan.
2020-09-21 21:53:53 +02:00
thread skipContext through to the instance node
2020-09-23 17:05:09 +02:00
// skipRefresh indicates that we should skip refreshing individual instances
skipRefresh bool
core: Minimal initial implementation of "refresh only" planning mode This only includes the core mechanisms to make it work. There's not yet any way to turn this mode on as an end-user, because we have to do some more work at the UI layer to present this well before we could include it as an end-user-visible feature in a release. At the lowest level of abstraction inside the graph nodes themselves, this effectively mirrors the existing option to disable refreshing with a new option to disable change-planning, so that either "half" of the process can be disabled. As far as the nodes are concerned it would be possible in principle to disable _both_, but the higher-level representation of these modes prevents that combination from reaching Terraform Core in practice, because we block using -refresh-only and -refresh=false at the same time.
2021-04-06 02:05:57 +02:00
// skipPlanChanges indicates we should skip trying to plan change actions
// for any instances.
skipPlanChanges bool
core: Minimal initial implementation of -replace=... option This only includes the internal mechanisms to make it work, and not any of the necessary UI changes to "terraform plan" and "terraform apply" to activate it yet. The force-replace options are ultimately handled inside the NodeAbstractResourceInstance.plan method, at the same place we handle the similar situation of the provider indicating that replacement is needed, and so the rest of the changes here are just to propagate the settings through all of the layers in order to reach that point.
2021-04-07 02:37:38 +02:00
// forceReplace are resource instance addresses where the user wants to
// force generating a replace action. This set isn't pre-filtered, so
// it might contain addresses that have nothing to do with the resource
// that this node represents, which the node itself must therefore ignore.
forceReplace []addrs.AbsResourceInstance
attach dependencies during plan This was previously done during refresh alone, now we need to insert these during the refresh portion of plan.
2020-09-21 21:53:53 +02:00
dependencies []addrs.ConfigResource
terraform: begin NodePlannableResource
2016-11-06 08:00:05 +01:00
}
terraform: ugly huge change to weave in new HCL2-oriented types Due to how deeply the configuration types go into Terraform Core, there isn't a great way to switch out to HCL2 gradually. As a consequence, this huge commit gets us from the old state to a _compilable_ new state, but does not yet attempt to fix any tests and has a number of known missing parts and bugs. We will continue to iterate on this in forthcoming commits, heading back towards passing tests and making Terraform fully-functional again. The three main goals here are: - Use the configuration models from the "configs" package instead of the older models in the "config" package, which is now deprecated and preserved only to help us write our migration tool. - Do expression inspection and evaluation using the functionality of the new "lang" package, instead of the Interpolator type and related functionality in the main "terraform" package. - Represent addresses of various objects using types in the addrs package, rather than hand-constructed strings. This is not critical to support the above, but was a big help during the implementation of these other points since it made it much more explicit what kind of address is expected in each context. Since our new packages are built to accommodate some future planned features that are not yet implemented (e.g. the "for_each" argument on resources, "count"/"for_each" on modules), and since there's still a fair amount of functionality still using old-style APIs, there is a moderate amount of shimming here to connect new assumptions with old, hopefully in a way that makes it easier to find and eliminate these shims later. I apologize in advance to the person who inevitably just found this huge commit while spelunking through the commit history.
2018-04-30 19:33:53 +02:00
var (
expand planned resources While the Expander itself now handles the recursive expansion of modules, Resources themselves still need to be expanded twice, because the evaluation of the Resource, which entails evaluating the for_each or count expressions, is separate from the ResourceInstance expansion. Add a nodeExpandPlannableResource to do handle this expansion to allow all NodePlannableResources to call EvalWriteResourceState with an absolute address.
2020-03-20 20:19:01 +01:00
_ GraphNodeModuleInstance = (*NodePlannableResource)(nil)
core: Handle forced-create_before_destroy during the plan walk Previously we used a single plan action "Replace" to represent both the destroy-before-create and the create-before-destroy variants of replacing. However, this forces the apply graph builder to jump through a lot of hoops to figure out which nodes need it forced on and rebuild parts of the graph to represent that. If we instead decide between these two cases at plan time, the actual determination of it is more straightforward because each resource is represented by only one node in the plan graph, and then we can ensure we put the right nodes in the graph during DiffTransformer and thus avoid the logic for dealing with deposed instances being spread across various different transformers and node types. As a nice side-effect, this also allows us to show the difference between destroy-then-create and create-then-destroy in the rendered diff in the CLI, although this change doesn't fully implement that yet.
2018-09-22 02:08:52 +02:00
_ GraphNodeDestroyerCBD = (*NodePlannableResource)(nil)
terraform: ugly huge change to weave in new HCL2-oriented types Due to how deeply the configuration types go into Terraform Core, there isn't a great way to switch out to HCL2 gradually. As a consequence, this huge commit gets us from the old state to a _compilable_ new state, but does not yet attempt to fix any tests and has a number of known missing parts and bugs. We will continue to iterate on this in forthcoming commits, heading back towards passing tests and making Terraform fully-functional again. The three main goals here are: - Use the configuration models from the "configs" package instead of the older models in the "config" package, which is now deprecated and preserved only to help us write our migration tool. - Do expression inspection and evaluation using the functionality of the new "lang" package, instead of the Interpolator type and related functionality in the main "terraform" package. - Represent addresses of various objects using types in the addrs package, rather than hand-constructed strings. This is not critical to support the above, but was a big help during the implementation of these other points since it made it much more explicit what kind of address is expected in each context. Since our new packages are built to accommodate some future planned features that are not yet implemented (e.g. the "for_each" argument on resources, "count"/"for_each" on modules), and since there's still a fair amount of functionality still using old-style APIs, there is a moderate amount of shimming here to connect new assumptions with old, hopefully in a way that makes it easier to find and eliminate these shims later. I apologize in advance to the person who inevitably just found this huge commit while spelunking through the commit history.
2018-04-30 19:33:53 +02:00
_ GraphNodeDynamicExpandable = (*NodePlannableResource)(nil)
_ GraphNodeReferenceable = (*NodePlannableResource)(nil)
_ GraphNodeReferencer = (*NodePlannableResource)(nil)
s/GraphNodeResource/GraphNodeConfigResource/ Make the interface name reflect the new return type of the method. Remove the confusingly named and unused ResourceAddress method from the resource nodes as well.
2020-03-15 16:32:06 +01:00
_ GraphNodeConfigResource = (*NodePlannableResource)(nil)
terraform: ugly huge change to weave in new HCL2-oriented types Due to how deeply the configuration types go into Terraform Core, there isn't a great way to switch out to HCL2 gradually. As a consequence, this huge commit gets us from the old state to a _compilable_ new state, but does not yet attempt to fix any tests and has a number of known missing parts and bugs. We will continue to iterate on this in forthcoming commits, heading back towards passing tests and making Terraform fully-functional again. The three main goals here are: - Use the configuration models from the "configs" package instead of the older models in the "config" package, which is now deprecated and preserved only to help us write our migration tool. - Do expression inspection and evaluation using the functionality of the new "lang" package, instead of the Interpolator type and related functionality in the main "terraform" package. - Represent addresses of various objects using types in the addrs package, rather than hand-constructed strings. This is not critical to support the above, but was a big help during the implementation of these other points since it made it much more explicit what kind of address is expected in each context. Since our new packages are built to accommodate some future planned features that are not yet implemented (e.g. the "for_each" argument on resources, "count"/"for_each" on modules), and since there's still a fair amount of functionality still using old-style APIs, there is a moderate amount of shimming here to connect new assumptions with old, hopefully in a way that makes it easier to find and eliminate these shims later. I apologize in advance to the person who inevitably just found this huge commit while spelunking through the commit history.
2018-04-30 19:33:53 +02:00
_ GraphNodeAttachResourceConfig = (*NodePlannableResource)(nil)
)
Add Path to more nodes that require it.
2020-03-23 13:56:55 +01:00
func (n *NodePlannableResource) Path() addrs.ModuleInstance {
return n.Addr.Module
}
cleanup some expanders
2020-03-24 20:19:12 +01:00
func (n *NodePlannableResource) Name() string {
return n.Addr.String()
}
terraform: refactor NodePlannableResource and NodeApplyableResource NodePlannableResource and NodeApplyableResource EvalTree()s have been replaced with Execute() nodes and straight-through code. Both called EvalWriteResourceState and were the only functions to use it, so I chose to replace EvalWriteResourceState entirely with straight-through code (by copying the contents into the two locations).
2020-09-24 21:30:58 +02:00
// GraphNodeExecutable
make GraphNodeExecutable return diagnostics
2020-10-28 18:47:04 +01:00
func (n *NodePlannableResource) Execute(ctx EvalContext, op walkOperation) tfdiags.Diagnostics {
core: -replace to emit only one warning for incomplete address If the user gives an index-less address for a resource that expects instance keys then previously we would've emitted one error per declared instance of the resource, which is overwhelming and not especially helpful. Instead, we'll deal with that check prior to expanding resources into resource instances, and thus we can report a single error which talks about all of the instances at once. This does unfortunately come at the expense of splitting the logic for dealing with the "force replace" addresses into two places, which will likely make later maintenance harder. In an attempt to mitigate that, I've included a comment in each place that mentions the other place, which hopefully future maintainers will keep up-to-date if that situation changes.
2021-05-01 01:55:53 +02:00
var diags tfdiags.Diagnostics
remove GraphNodeModuleInstance from Resource types Remove the requirement for most *Resource types to be a GraphNodeModuleInstance, ensuring that they never call ctx.Path while being evaluated. This gets rid of most of the direct need for the Path method currently implemented by NodeResourceAbstract, leaving the provider and schema related calls for a subsequent PR.
2020-03-09 20:43:56 +01:00
if n.Config == nil {
make NodePlannableResource eval-able Eval a NodePlannableResource before expanding it, to ensure that it can be referenced even if the count is 0.
2018-09-20 03:30:16 +02:00
// Nothing to do, then.
remove GraphNodeModuleInstance from Resource types Remove the requirement for most *Resource types to be a GraphNodeModuleInstance, ensuring that they never call ctx.Path while being evaluated. This gets rid of most of the direct need for the Path method currently implemented by NodeResourceAbstract, leaving the provider and schema related calls for a subsequent PR.
2020-03-09 20:43:56 +01:00
log.Printf("[TRACE] NodeApplyableResource: no configuration present for %s", n.Name())
core: -replace to emit only one warning for incomplete address If the user gives an index-less address for a resource that expects instance keys then previously we would've emitted one error per declared instance of the resource, which is overwhelming and not especially helpful. Instead, we'll deal with that check prior to expanding resources into resource instances, and thus we can report a single error which talks about all of the instances at once. This does unfortunately come at the expense of splitting the logic for dealing with the "force replace" addresses into two places, which will likely make later maintenance harder. In an attempt to mitigate that, I've included a comment in each place that mentions the other place, which hopefully future maintainers will keep up-to-date if that situation changes.
2021-05-01 01:55:53 +02:00
return diags
}
// writeResourceState is responsible for informing the expander of what
// repetition mode this resource has, which allows expander.ExpandResource
// to work below.
moreDiags := n.writeResourceState(ctx, n.Addr)
diags = diags.Append(moreDiags)
if moreDiags.HasErrors() {
return diags
}
// Before we expand our resource into potentially many resource instances,
// we'll verify that any mention of this resource in n.forceReplace is
// consistent with the repetition mode of the resource. In other words,
// we're aiming to catch a situation where naming a particular resource
// instance would require an instance key but the given address has none.
expander := ctx.InstanceExpander()
instanceAddrs := expander.ExpandResource(n.ResourceAddr().Absolute(ctx.Path()))
// If there's a number of instances other than 1 then we definitely need
// an index.
mustHaveIndex := len(instanceAddrs) != 1
// If there's only one instance then we might still need an index, if the
// instance address has one.
if len(instanceAddrs) == 1 && instanceAddrs[0].Resource.Key != addrs.NoKey {
mustHaveIndex = true
}
if mustHaveIndex {
for _, candidateAddr := range n.forceReplace {
if candidateAddr.Resource.Key == addrs.NoKey {
if n.Addr.Resource.Equal(candidateAddr.Resource.Resource) {
switch {
case len(instanceAddrs) == 0:
// In this case there _are_ no instances to replace, so
// there isn't any alternative address for us to suggest.
diags = diags.Append(tfdiags.Sourceless(
tfdiags.Warning,
"Incompletely-matched force-replace resource instance",
fmt.Sprintf(
"Your force-replace request for %s doesn't match any resource instances because this resource doesn't have any instances.",
candidateAddr,
),
))
case len(instanceAddrs) == 1:
diags = diags.Append(tfdiags.Sourceless(
tfdiags.Warning,
"Incompletely-matched force-replace resource instance",
fmt.Sprintf(
"Your force-replace request for %s doesn't match any resource instances because it lacks an instance key.\n\nTo force replacement of the single declared instance, use the following option instead:\n -replace=%q",
candidateAddr, instanceAddrs[0],
),
))
default:
var possibleValidOptions strings.Builder
for _, addr := range instanceAddrs {
fmt.Fprintf(&possibleValidOptions, "\n -replace=%q", addr)
}
diags = diags.Append(tfdiags.Sourceless(
tfdiags.Warning,
"Incompletely-matched force-replace resource instance",
fmt.Sprintf(
"Your force-replace request for %s doesn't match any resource instances because it lacks an instance key.\n\nTo force replacement of particular instances, use one or more of the following options instead:%s",
candidateAddr, possibleValidOptions.String(),
),
))
}
}
}
}
make NodePlannableResource eval-able Eval a NodePlannableResource before expanding it, to ensure that it can be referenced even if the count is 0.
2018-09-20 03:30:16 +02:00
}
core: -replace to emit only one warning for incomplete address If the user gives an index-less address for a resource that expects instance keys then previously we would've emitted one error per declared instance of the resource, which is overwhelming and not especially helpful. Instead, we'll deal with that check prior to expanding resources into resource instances, and thus we can report a single error which talks about all of the instances at once. This does unfortunately come at the expense of splitting the logic for dealing with the "force replace" addresses into two places, which will likely make later maintenance harder. In an attempt to mitigate that, I've included a comment in each place that mentions the other place, which hopefully future maintainers will keep up-to-date if that situation changes.
2021-05-01 01:55:53 +02:00
// NOTE: The actual interpretation of n.forceReplace to produce replace
// actions is in NodeAbstractResourceInstance.plan, because we must do so
// on a per-instance basis rather than for the whole resource.
make NodePlannableResource eval-able Eval a NodePlannableResource before expanding it, to ensure that it can be referenced even if the count is 0.
2018-09-20 03:30:16 +02:00
core: -replace to emit only one warning for incomplete address If the user gives an index-less address for a resource that expects instance keys then previously we would've emitted one error per declared instance of the resource, which is overwhelming and not especially helpful. Instead, we'll deal with that check prior to expanding resources into resource instances, and thus we can report a single error which talks about all of the instances at once. This does unfortunately come at the expense of splitting the logic for dealing with the "force replace" addresses into two places, which will likely make later maintenance harder. In an attempt to mitigate that, I've included a comment in each place that mentions the other place, which hopefully future maintainers will keep up-to-date if that situation changes.
2021-05-01 01:55:53 +02:00
return diags
make NodePlannableResource eval-able Eval a NodePlannableResource before expanding it, to ensure that it can be referenced even if the count is 0.
2018-09-20 03:30:16 +02:00
}
core: Handle forced-create_before_destroy during the plan walk Previously we used a single plan action "Replace" to represent both the destroy-before-create and the create-before-destroy variants of replacing. However, this forces the apply graph builder to jump through a lot of hoops to figure out which nodes need it forced on and rebuild parts of the graph to represent that. If we instead decide between these two cases at plan time, the actual determination of it is more straightforward because each resource is represented by only one node in the plan graph, and then we can ensure we put the right nodes in the graph during DiffTransformer and thus avoid the logic for dealing with deposed instances being spread across various different transformers and node types. As a nice side-effect, this also allows us to show the difference between destroy-then-create and create-then-destroy in the rendered diff in the CLI, although this change doesn't fully implement that yet.
2018-09-22 02:08:52 +02:00
// GraphNodeDestroyerCBD
func (n *NodePlannableResource) CreateBeforeDestroy() bool {
if n.ForceCreateBeforeDestroy != nil {
return *n.ForceCreateBeforeDestroy
}
// If we have no config, we just assume no
if n.Config == nil || n.Config.Managed == nil {
return false
}
return n.Config.Managed.CreateBeforeDestroy
}
// GraphNodeDestroyerCBD
func (n *NodePlannableResource) ModifyCreateBeforeDestroy(v bool) error {
n.ForceCreateBeforeDestroy = &v
return nil
}
terraform: ResourceTransformer to ResourceTransformerOld
2016-11-06 19:07:17 +01:00
// GraphNodeDynamicExpandable
func (n *NodePlannableResource) DynamicExpand(ctx EvalContext) (*Graph, error) {
terraform: ugly huge change to weave in new HCL2-oriented types Due to how deeply the configuration types go into Terraform Core, there isn't a great way to switch out to HCL2 gradually. As a consequence, this huge commit gets us from the old state to a _compilable_ new state, but does not yet attempt to fix any tests and has a number of known missing parts and bugs. We will continue to iterate on this in forthcoming commits, heading back towards passing tests and making Terraform fully-functional again. The three main goals here are: - Use the configuration models from the "configs" package instead of the older models in the "config" package, which is now deprecated and preserved only to help us write our migration tool. - Do expression inspection and evaluation using the functionality of the new "lang" package, instead of the Interpolator type and related functionality in the main "terraform" package. - Represent addresses of various objects using types in the addrs package, rather than hand-constructed strings. This is not critical to support the above, but was a big help during the implementation of these other points since it made it much more explicit what kind of address is expected in each context. Since our new packages are built to accommodate some future planned features that are not yet implemented (e.g. the "for_each" argument on resources, "count"/"for_each" on modules), and since there's still a fair amount of functionality still using old-style APIs, there is a moderate amount of shimming here to connect new assumptions with old, hopefully in a way that makes it easier to find and eliminate these shims later. I apologize in advance to the person who inevitably just found this huge commit while spelunking through the commit history.
2018-04-30 19:33:53 +02:00
var diags tfdiags.Diagnostics
core: Use instances.Expander to handle resource count and for_each This is a minimal integration of instances.Expander used just for resource count and for_each, for now just forcing modules to always be singletons because the rest of Terraform Core isn't ready to deal with expanding module calls yet. This doesn't integrate super cleanly yet because we still have some cleanup work to do in the design of the plan walk, to make it explicit that the nodes in the plan graph represent static configuration objects rather than expanded instances, including for modules. To make this work in the meantime, there is some shimming between addrs.Module and addrs.ModuleInstance to correct for the discontinuities that result from the fact that Terraform currently assumes that modules are always singletons.
2019-11-22 03:45:43 +01:00
// Our instance expander should already have been informed about the
// expansion of this resource and of all of its containing modules, so
// it can tell us which instance addresses we need to process.
expander := ctx.InstanceExpander()
udpate core to work with new ExpandResource This also calls ExpandModuleResource in one location, because the logic is not yet updated to handle actual module expansion, but that will be fixed in a forthcoming PR.
2020-03-24 17:11:27 +01:00
instanceAddrs := expander.ExpandResource(n.ResourceAddr().Absolute(ctx.Path()))
core: Use instances.Expander to handle resource count and for_each This is a minimal integration of instances.Expander used just for resource count and for_each, for now just forcing modules to always be singletons because the rest of Terraform Core isn't ready to deal with expanding module calls yet. This doesn't integrate super cleanly yet because we still have some cleanup work to do in the design of the plan walk, to make it explicit that the nodes in the plan graph represent static configuration objects rather than expanded instances, including for modules. To make this work in the meantime, there is some shimming between addrs.Module and addrs.ModuleInstance to correct for the discontinuities that result from the fact that Terraform currently assumes that modules are always singletons.
2019-11-22 03:45:43 +01:00
terraform: Ugly huge change to weave in new State and Plan types Due to how often the state and plan types are referenced throughout Terraform, there isn't a great way to switch them out gradually. As a consequence, this huge commit gets us from the old world to a _compilable_ new world, but still has a large number of known test failures due to key functionality being stubbed out. The stubs here are for anything that interacts with providers, since we now need to do the follow-up work to similarly replace the old terraform.ResourceProvider interface with its replacement in the new "providers" package. That work, along with work to fix the remaining failing tests, will follow in subsequent commits. The aim here was to replace all references to terraform.State and its downstream types with states.State, terraform.Plan with plans.Plan, state.State with statemgr.State, and switch to the new implementations of the state and plan file formats. However, due to the number of times those types are used, this also ended up affecting numerous other parts of core such as terraform.Hook, the backend.Backend interface, and most of the CLI commands. Just as with 5861dbf3fc49b19587a31816eb06f511ab861bb4 before, I apologize in advance to the person who inevitably just found this huge commit while spelunking through the commit history.
2018-08-14 23:24:45 +02:00
// Our graph transformers require access to the full state, so we'll
// temporarily lock it while we work on this.
state := ctx.State().Lock()
defer ctx.State().Unlock()
terraform: OrphanResourceCountTransformer for orphaning extranneous instances
2016-11-07 22:23:06 +01:00
terraform: expand count in plan
2016-11-06 19:15:09 +01:00
// The concrete resource factory we'll use
terraform: ugly huge change to weave in new HCL2-oriented types Due to how deeply the configuration types go into Terraform Core, there isn't a great way to switch out to HCL2 gradually. As a consequence, this huge commit gets us from the old state to a _compilable_ new state, but does not yet attempt to fix any tests and has a number of known missing parts and bugs. We will continue to iterate on this in forthcoming commits, heading back towards passing tests and making Terraform fully-functional again. The three main goals here are: - Use the configuration models from the "configs" package instead of the older models in the "config" package, which is now deprecated and preserved only to help us write our migration tool. - Do expression inspection and evaluation using the functionality of the new "lang" package, instead of the Interpolator type and related functionality in the main "terraform" package. - Represent addresses of various objects using types in the addrs package, rather than hand-constructed strings. This is not critical to support the above, but was a big help during the implementation of these other points since it made it much more explicit what kind of address is expected in each context. Since our new packages are built to accommodate some future planned features that are not yet implemented (e.g. the "for_each" argument on resources, "count"/"for_each" on modules), and since there's still a fair amount of functionality still using old-style APIs, there is a moderate amount of shimming here to connect new assumptions with old, hopefully in a way that makes it easier to find and eliminate these shims later. I apologize in advance to the person who inevitably just found this huge commit while spelunking through the commit history.
2018-04-30 19:33:53 +02:00
concreteResource := func(a *NodeAbstractResourceInstance) dag.Vertex {
terraform: expand count in plan
2016-11-06 19:15:09 +01:00
// Add the config and state since we don't do that via transforms
a.Config = n.Config
WIP reference providers by full name This turned out to be a big messy commit, since the way providers are referenced is tightly coupled throughout the code. That starts to unify how providers are referenced, using the format output node Name method. Add a new field to the internal resource data types called ResolvedProvider. This is set by a new setter method SetProvider when a resource is connected to a provider during graph creation. This allows us to later lookup the provider instance a resource is connected to, without requiring it to have the same module path. The InitProvider context method now takes 2 arguments, one if the provider type and the second is the full name of the provider. While the provider type could still be parsed from the full name, this makes it more explicit and, and changes to the name format won't effect this code.
2017-11-01 23:34:18 +01:00
a.ResolvedProvider = n.ResolvedProvider
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 21:39:45 +02:00
a.Schema = n.Schema
core: attach provisioner schemas in subgraphs DynamicExpand also needs to add the provisioner schemas to make sure all references are found in the subgraph.
2018-06-02 00:04:28 +02:00
a.ProvisionerSchemas = n.ProvisionerSchemas
Add support for provider metadata to modules. (#22583) Implement a new provider_meta block in the terraform block of modules, allowing provider-keyed metadata to be communicated from HCL to provider binaries. Bundled in this change for minimal protocol version bumping is the addition of markdown support for attribute descriptions and the ability to indicate when an attribute is deprecated, so this information can be shown in the schema dump. Co-authored-by: Paul Tyng <paul@paultyng.net>
2020-03-06 01:53:24 +01:00
a.ProviderMetas = n.ProviderMetas
add GraphNodeAttachDependsOn GraphNodeAttachDependsOn give us a method for adding all transitive resource dependencies found through depends_on references, so that data source can determine if they can be read during plan. This will be done by inspecting the changes of all dependency resources, and delaying read until apply if any changes are planned.
2020-05-01 16:22:50 +02:00
a.dependsOn = n.dependsOn
attach dependencies during plan This was previously done during refresh alone, now we need to insert these during the refresh portion of plan.
2020-09-21 21:53:53 +02:00
a.Dependencies = n.dependencies
terraform: expand count in plan
2016-11-06 19:15:09 +01:00
return &NodePlannableResourceInstance{
terraform: ugly huge change to weave in new HCL2-oriented types Due to how deeply the configuration types go into Terraform Core, there isn't a great way to switch out to HCL2 gradually. As a consequence, this huge commit gets us from the old state to a _compilable_ new state, but does not yet attempt to fix any tests and has a number of known missing parts and bugs. We will continue to iterate on this in forthcoming commits, heading back towards passing tests and making Terraform fully-functional again. The three main goals here are: - Use the configuration models from the "configs" package instead of the older models in the "config" package, which is now deprecated and preserved only to help us write our migration tool. - Do expression inspection and evaluation using the functionality of the new "lang" package, instead of the Interpolator type and related functionality in the main "terraform" package. - Represent addresses of various objects using types in the addrs package, rather than hand-constructed strings. This is not critical to support the above, but was a big help during the implementation of these other points since it made it much more explicit what kind of address is expected in each context. Since our new packages are built to accommodate some future planned features that are not yet implemented (e.g. the "for_each" argument on resources, "count"/"for_each" on modules), and since there's still a fair amount of functionality still using old-style APIs, there is a moderate amount of shimming here to connect new assumptions with old, hopefully in a way that makes it easier to find and eliminate these shims later. I apologize in advance to the person who inevitably just found this huge commit while spelunking through the commit history.
2018-04-30 19:33:53 +02:00
NodeAbstractResourceInstance: a,
core: Handle forced-create_before_destroy during the plan walk Previously we used a single plan action "Replace" to represent both the destroy-before-create and the create-before-destroy variants of replacing. However, this forces the apply graph builder to jump through a lot of hoops to figure out which nodes need it forced on and rebuild parts of the graph to represent that. If we instead decide between these two cases at plan time, the actual determination of it is more straightforward because each resource is represented by only one node in the plan graph, and then we can ensure we put the right nodes in the graph during DiffTransformer and thus avoid the logic for dealing with deposed instances being spread across various different transformers and node types. As a nice side-effect, this also allows us to show the difference between destroy-then-create and create-then-destroy in the rendered diff in the CLI, although this change doesn't fully implement that yet.
2018-09-22 02:08:52 +02:00
// By the time we're walking, we've figured out whether we need
// to force on CreateBeforeDestroy due to dependencies on other
// nodes that have it.
ForceCreateBeforeDestroy: n.CreateBeforeDestroy(),
thread skipContext through to the instance node
2020-09-23 17:05:09 +02:00
skipRefresh: n.skipRefresh,
core: Minimal initial implementation of "refresh only" planning mode This only includes the core mechanisms to make it work. There's not yet any way to turn this mode on as an end-user, because we have to do some more work at the UI layer to present this well before we could include it as an end-user-visible feature in a release. At the lowest level of abstraction inside the graph nodes themselves, this effectively mirrors the existing option to disable refreshing with a new option to disable change-planning, so that either "half" of the process can be disabled. As far as the nodes are concerned it would be possible in principle to disable _both_, but the higher-level representation of these modes prevents that combination from reaching Terraform Core in practice, because we block using -refresh-only and -refresh=false at the same time.
2021-04-06 02:05:57 +02:00
skipPlanChanges: n.skipPlanChanges,
core: Minimal initial implementation of -replace=... option This only includes the internal mechanisms to make it work, and not any of the necessary UI changes to "terraform plan" and "terraform apply" to activate it yet. The force-replace options are ultimately handled inside the NodeAbstractResourceInstance.plan method, at the same place we handle the similar situation of the provider indicating that replacement is needed, and so the rest of the changes here are just to propagate the settings through all of the layers in order to reach that point.
2021-04-07 02:37:38 +02:00
forceReplace: n.forceReplace,
terraform: expand count in plan
2016-11-06 19:15:09 +01:00
}
}
terraform: ResourceTransformer to ResourceTransformerOld
2016-11-06 19:07:17 +01:00
terraform: ugly huge change to weave in new HCL2-oriented types Due to how deeply the configuration types go into Terraform Core, there isn't a great way to switch out to HCL2 gradually. As a consequence, this huge commit gets us from the old state to a _compilable_ new state, but does not yet attempt to fix any tests and has a number of known missing parts and bugs. We will continue to iterate on this in forthcoming commits, heading back towards passing tests and making Terraform fully-functional again. The three main goals here are: - Use the configuration models from the "configs" package instead of the older models in the "config" package, which is now deprecated and preserved only to help us write our migration tool. - Do expression inspection and evaluation using the functionality of the new "lang" package, instead of the Interpolator type and related functionality in the main "terraform" package. - Represent addresses of various objects using types in the addrs package, rather than hand-constructed strings. This is not critical to support the above, but was a big help during the implementation of these other points since it made it much more explicit what kind of address is expected in each context. Since our new packages are built to accommodate some future planned features that are not yet implemented (e.g. the "for_each" argument on resources, "count"/"for_each" on modules), and since there's still a fair amount of functionality still using old-style APIs, there is a moderate amount of shimming here to connect new assumptions with old, hopefully in a way that makes it easier to find and eliminate these shims later. I apologize in advance to the person who inevitably just found this huge commit while spelunking through the commit history.
2018-04-30 19:33:53 +02:00
// The concrete resource factory we'll use for orphans
concreteResourceOrphan := func(a *NodeAbstractResourceInstance) dag.Vertex {
terraform: output the exact instance for prevent destroy on count
2016-11-07 23:05:21 +01:00
// Add the config and state since we don't do that via transforms
a.Config = n.Config
WIP reference providers by full name This turned out to be a big messy commit, since the way providers are referenced is tightly coupled throughout the code. That starts to unify how providers are referenced, using the format output node Name method. Add a new field to the internal resource data types called ResolvedProvider. This is set by a new setter method SetProvider when a resource is connected to a provider during graph creation. This allows us to later lookup the provider instance a resource is connected to, without requiring it to have the same module path. The InitProvider context method now takes 2 arguments, one if the provider type and the second is the full name of the provider. While the provider type could still be parsed from the full name, this makes it more explicit and, and changes to the name format won't effect this code.
2017-11-01 23:34:18 +01:00
a.ResolvedProvider = n.ResolvedProvider
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 21:39:45 +02:00
a.Schema = n.Schema
core: attach provisioner schemas in subgraphs DynamicExpand also needs to add the provisioner schemas to make sure all references are found in the subgraph.
2018-06-02 00:04:28 +02:00
a.ProvisionerSchemas = n.ProvisionerSchemas
Add support for provider metadata to modules. (#22583) Implement a new provider_meta block in the terraform block of modules, allowing provider-keyed metadata to be communicated from HCL to provider binaries. Bundled in this change for minimal protocol version bumping is the addition of markdown support for attribute descriptions and the ability to indicate when an attribute is deprecated, so this information can be shown in the schema dump. Co-authored-by: Paul Tyng <paul@paultyng.net>
2020-03-06 01:53:24 +01:00
a.ProviderMetas = n.ProviderMetas
terraform: output the exact instance for prevent destroy on count
2016-11-07 23:05:21 +01:00
terraform: ugly huge change to weave in new HCL2-oriented types Due to how deeply the configuration types go into Terraform Core, there isn't a great way to switch out to HCL2 gradually. As a consequence, this huge commit gets us from the old state to a _compilable_ new state, but does not yet attempt to fix any tests and has a number of known missing parts and bugs. We will continue to iterate on this in forthcoming commits, heading back towards passing tests and making Terraform fully-functional again. The three main goals here are: - Use the configuration models from the "configs" package instead of the older models in the "config" package, which is now deprecated and preserved only to help us write our migration tool. - Do expression inspection and evaluation using the functionality of the new "lang" package, instead of the Interpolator type and related functionality in the main "terraform" package. - Represent addresses of various objects using types in the addrs package, rather than hand-constructed strings. This is not critical to support the above, but was a big help during the implementation of these other points since it made it much more explicit what kind of address is expected in each context. Since our new packages are built to accommodate some future planned features that are not yet implemented (e.g. the "for_each" argument on resources, "count"/"for_each" on modules), and since there's still a fair amount of functionality still using old-style APIs, there is a moderate amount of shimming here to connect new assumptions with old, hopefully in a way that makes it easier to find and eliminate these shims later. I apologize in advance to the person who inevitably just found this huge commit while spelunking through the commit history.
2018-04-30 19:33:53 +02:00
return &NodePlannableResourceInstanceOrphan{
NodeAbstractResourceInstance: a,
core: Track both previous run state and refresh state during planning The "previous run state" is our record of what the previous run of Terraform considered to be its outcome, but in order to do anything useful with that we must ensure that the data inside conforms to the current resource type schemas, which might be different than the schemas that were current during the previous run if the relevant provider has since been upgraded. For that reason then, we'll start off with the previous run state set exactly equal to what was saved in the prior snapshot (modulo any changes that happened during a state file format upgrade) but then during our planning operation we'll overwrite individual resource instance objects with the result of upgrading, so that in a situation where we successfully run plan to completion the previous run state should always have a compatible schema with the "prior state" (the result of refreshing) for managed resources, and thus the caller can meaningfully compare the two in order to detect and describe any out-of-band changes that occurred since the previous run.
2021-05-05 03:14:43 +02:00
skipRefresh: n.skipRefresh,
core: Fix refresh-only interaction with orphans When planning in refresh-only mode, we must not remove orphaned resources due to changed count or for_each values from the planned state. This was previously happening because we failed to pass through the plan's skip-plan-changes flag to the instance orphan node.
2021-09-23 22:38:08 +02:00
skipPlanChanges: n.skipPlanChanges,
terraform: OrphanResourceCountTransformer for orphaning extranneous instances
2016-11-07 22:23:06 +01:00
}
}
terraform: ResourceTransformer to ResourceTransformerOld
2016-11-06 19:07:17 +01:00
// Start creating the steps
terraform: OrphanResourceCountTransformer for orphaning extranneous instances
2016-11-07 22:23:06 +01:00
steps := []GraphTransformer{
Resource for_each
2019-06-12 17:07:32 +02:00
// Expand the count or for_each (if present)
terraform: OrphanResourceCountTransformer for orphaning extranneous instances
2016-11-07 22:23:06 +01:00
&ResourceCountTransformer{
core: Use instances.Expander to handle resource count and for_each This is a minimal integration of instances.Expander used just for resource count and for_each, for now just forcing modules to always be singletons because the rest of Terraform Core isn't ready to deal with expanding module calls yet. This doesn't integrate super cleanly yet because we still have some cleanup work to do in the design of the plan walk, to make it explicit that the nodes in the plan graph represent static configuration objects rather than expanded instances, including for modules. To make this work in the meantime, there is some shimming between addrs.Module and addrs.ModuleInstance to correct for the discontinuities that result from the fact that Terraform currently assumes that modules are always singletons.
2019-11-22 03:45:43 +01:00
Concrete: concreteResource,
Schema: n.Schema,
Addr: n.ResourceAddr(),
InstanceAddrs: instanceAddrs,
terraform: OrphanResourceCountTransformer for orphaning extranneous instances
2016-11-07 22:23:06 +01:00
},
Resource for_each
2019-06-12 17:07:32 +02:00
// Add the count/for_each orphans
expansion resource and instance orphans When a module instances is removed, we need to add both the instance and resource deletion nodes from that module.
2020-03-27 22:16:08 +01:00
&OrphanResourceInstanceCountTransformer{
core: Use instances.Expander to handle resource count and for_each This is a minimal integration of instances.Expander used just for resource count and for_each, for now just forcing modules to always be singletons because the rest of Terraform Core isn't ready to deal with expanding module calls yet. This doesn't integrate super cleanly yet because we still have some cleanup work to do in the design of the plan walk, to make it explicit that the nodes in the plan graph represent static configuration objects rather than expanded instances, including for modules. To make this work in the meantime, there is some shimming between addrs.Module and addrs.ModuleInstance to correct for the discontinuities that result from the fact that Terraform currently assumes that modules are always singletons.
2019-11-22 03:45:43 +01:00
Concrete: concreteResourceOrphan,
orphan resources needs to use AbsResource The expand logic was separated into nodeExpandRefreshableManagedResource, but the orphan logic wasn't updated.
2020-03-25 20:07:35 +01:00
Addr: n.Addr,
core: Use instances.Expander to handle resource count and for_each This is a minimal integration of instances.Expander used just for resource count and for_each, for now just forcing modules to always be singletons because the rest of Terraform Core isn't ready to deal with expanding module calls yet. This doesn't integrate super cleanly yet because we still have some cleanup work to do in the design of the plan walk, to make it explicit that the nodes in the plan graph represent static configuration objects rather than expanded instances, including for modules. To make this work in the meantime, there is some shimming between addrs.Module and addrs.ModuleInstance to correct for the discontinuities that result from the fact that Terraform currently assumes that modules are always singletons.
2019-11-22 03:45:43 +01:00
InstanceAddrs: instanceAddrs,
State: state,
terraform: OrphanResourceCountTransformer for orphaning extranneous instances
2016-11-07 22:23:06 +01:00
},
terraform: ResourceTransformer to ResourceTransformerOld
2016-11-06 19:07:17 +01:00
terraform: OrphanResourceCountTransformer for orphaning extranneous instances
2016-11-07 22:23:06 +01:00
// Attach the state
&AttachStateTransformer{State: state},
terraform: enable targeting on expanded nodes
2016-11-08 02:45:08 +01:00
// Targeting
terraform: ugly huge change to weave in new HCL2-oriented types Due to how deeply the configuration types go into Terraform Core, there isn't a great way to switch out to HCL2 gradually. As a consequence, this huge commit gets us from the old state to a _compilable_ new state, but does not yet attempt to fix any tests and has a number of known missing parts and bugs. We will continue to iterate on this in forthcoming commits, heading back towards passing tests and making Terraform fully-functional again. The three main goals here are: - Use the configuration models from the "configs" package instead of the older models in the "config" package, which is now deprecated and preserved only to help us write our migration tool. - Do expression inspection and evaluation using the functionality of the new "lang" package, instead of the Interpolator type and related functionality in the main "terraform" package. - Represent addresses of various objects using types in the addrs package, rather than hand-constructed strings. This is not critical to support the above, but was a big help during the implementation of these other points since it made it much more explicit what kind of address is expected in each context. Since our new packages are built to accommodate some future planned features that are not yet implemented (e.g. the "for_each" argument on resources, "count"/"for_each" on modules), and since there's still a fair amount of functionality still using old-style APIs, there is a moderate amount of shimming here to connect new assumptions with old, hopefully in a way that makes it easier to find and eliminate these shims later. I apologize in advance to the person who inevitably just found this huge commit while spelunking through the commit history.
2018-04-30 19:33:53 +02:00
&TargetsTransformer{Targets: n.Targets},
terraform: enable targeting on expanded nodes
2016-11-08 02:45:08 +01:00
terraform: connect references
2016-11-07 22:55:35 +01:00
// Connect references so ordering is correct
&ReferenceTransformer{},
terraform: OrphanResourceCountTransformer for orphaning extranneous instances
2016-11-07 22:23:06 +01:00
// Make sure there is a single root
&RootTransformer{},
}
terraform: ResourceTransformer to ResourceTransformerOld
2016-11-06 19:07:17 +01:00
// Build the graph
Make sure each GraphBuilder has a Name Ensure that each instance of BasucGraphBuilder gets a name corresponding to the Builder which created it. This allows us to differentiate the graphs in the logs.
2016-11-15 22:36:10 +01:00
b := &BasicGraphBuilder{
Steps: steps,
Validate: true,
Name: "NodePlannableResource",
}
terraform: ugly huge change to weave in new HCL2-oriented types Due to how deeply the configuration types go into Terraform Core, there isn't a great way to switch out to HCL2 gradually. As a consequence, this huge commit gets us from the old state to a _compilable_ new state, but does not yet attempt to fix any tests and has a number of known missing parts and bugs. We will continue to iterate on this in forthcoming commits, heading back towards passing tests and making Terraform fully-functional again. The three main goals here are: - Use the configuration models from the "configs" package instead of the older models in the "config" package, which is now deprecated and preserved only to help us write our migration tool. - Do expression inspection and evaluation using the functionality of the new "lang" package, instead of the Interpolator type and related functionality in the main "terraform" package. - Represent addresses of various objects using types in the addrs package, rather than hand-constructed strings. This is not critical to support the above, but was a big help during the implementation of these other points since it made it much more explicit what kind of address is expected in each context. Since our new packages are built to accommodate some future planned features that are not yet implemented (e.g. the "for_each" argument on resources, "count"/"for_each" on modules), and since there's still a fair amount of functionality still using old-style APIs, there is a moderate amount of shimming here to connect new assumptions with old, hopefully in a way that makes it easier to find and eliminate these shims later. I apologize in advance to the person who inevitably just found this huge commit while spelunking through the commit history.
2018-04-30 19:33:53 +02:00
graph, diags := b.Build(ctx.Path())
return graph, diags.ErrWithWarnings()
terraform: begin NodePlannableResource
2016-11-06 08:00:05 +01:00
}