Commit Graph

22 Commits

Author SHA1 Message Date
Martin Atkins
c937c06a03 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-10-16 18:46:46 -07:00
James Bardin
620f1985a1 unused outputs in a destroy should be pruned
During a full destroy when outputs are removed, the
NodeDestroyableOutput was preventing it's sibling output from being
destroyed. Prune the output node if it only has its destroy node as a
dependent.

The destroy output test is simply run a second time with no state, which
would cause the output interpolation to fail if it remained in the
graph.
2018-04-03 13:19:04 -04:00
James Bardin
99867f0082 add PruneUnusedValuesTransformer
Since outputs and local nodes are always evaluated, if the reference a
resource form the configuration that isn't in the state, the
interpolation could fail.

Prune any local or output values that have no references in the graph.
2018-01-30 10:47:17 -05:00
James Bardin
d31fe5ab9d delete outputs during destroy
Now that outputs are always evaluated, we still need a way to remove
them from state when they are destroyed.

Previously, outputs were removed during destroy from the same
"Applyable" node type that evaluates them. Now that we need to possibly
both evaluate and remove output during an apply, we add a new node -
NodeDestroyableOutput.

This new node is added to the graph by the DestroyOutputTransformer,
which make the new destroy node depend on all descendants of the output
node.  This ensures that the output remains in the state as long as
everything which may interpolate the output still exists.
2018-01-29 19:30:04 -05:00
James Bardin
08139557f8 always evaluate outputs too
Always evaluate outputs during destroy, just like we did for locals.
This breaks existing tests, which we will handle separately.

Don't reverse output/local node evaluation order during destroy, as they
are both being evaluated.
2018-01-29 18:10:34 -05:00
James Bardin
7da1a39480 always evaluate locals, even during destroy
Destroy-time provisioners require us to re-evaluate during destroy.

Rather than destroying local values, which doesn't do much since they
aren't persisted to state, we always evaluate them regardless of the
type of apply. Since the destroy-time local node is no longer a
"destroy" operation, the order of evaluation need to be reversed. Take
the existing DestroyValueReferenceTransformer and change it to reverse
the outgoing edges, rather than in incoming edges. This makes it so that
any dependencies of a local or output node are destroyed after
evaluation.

Having locals evaluated during destroy failed one other test, but that
was the odd case where we need `id` to exist as an attribute as well as
a field.
2018-01-29 16:16:41 -05:00
James Bardin
e0ad3300c6 fix References used by the ReferenceTransformer
There was a bug where all references would be discarded in the case when
a self-reference was encountered. Since a module references all
descendants by it's own path, it returns a self-reference by definition.
2017-11-09 10:36:42 -05:00
James Bardin
a14fd0344c 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-02 15:00:06 -04:00
James Bardin
35c6a4e89d add DestroyValueReferenceTransformer
DestroyValueReferenceTransformer is used during destroy to reverse the
edges for output and local values. Because destruction is going to
remove these from the state, nodes that depend on their value need to be
visited first.
2017-10-02 16:20:29 -04:00
Martin Atkins
5b66953d1d core: graph nodes and edges for local values
A local value is similar to an output in that it exists only within state
and just always evaluates its value as best it can with the current state.
Therefore it has a single graph node type for all walks, which will
deal with that evaluation operation.
2017-08-21 15:15:25 -07:00
Mitchell Hashimoto
a6bab455cc terraform: remove node module file 2017-01-26 20:05:42 -08:00
Mitchell Hashimoto
538302f143 terraform: resources nested within a module must also be depended on
For example: A => B => C (modules). If A depends on module B, then it
also must depend on everything in module C.
2016-11-12 15:38:28 -08:00
Mitchell Hashimoto
0b87ef82c3 terraform: depends_on can reference entire modules 2016-11-12 08:07:45 -08:00
Mitchell Hashimoto
19350d617d terraform: references can have backups
terraform: more specific resource references

terraform: outputs need to know about the new reference format

terraform: resources w/o a config still have a referencable name
2016-11-08 13:59:30 -08:00
Mitchell Hashimoto
6914d605c8 terraform: connect references 2016-11-08 13:59:28 -08:00
Mitchell Hashimoto
a5df3973a4 terraform: module variables should be pruned if nothing depends on them 2016-11-04 18:58:03 -07:00
Mitchell Hashimoto
38b9f7794d terraform: reference transformer shouldn't make loop to self 2016-10-19 13:38:52 -07:00
Mitchell Hashimoto
4dfdc52ba0 terraform: first stap at module variables, going to redo some things 2016-10-19 13:38:51 -07:00
Mitchell Hashimoto
f2aa880625 terraform: proper prefix for output connects 2016-10-19 13:38:50 -07:00
Mitchell Hashimoto
7d07f20893 terraform: fix references to module outputs 2016-10-19 13:38:50 -07:00
Mitchell Hashimoto
0d7674b079 terraform: apply builder adds outputs to graphs 2016-10-19 13:38:50 -07:00
Mitchell Hashimoto
994f5ce773 terraform: ReferenceTransform to connect references 2016-10-19 13:38:50 -07:00