Commit Graph

22 Commits

Author SHA1 Message Date
James Bardin
009a136fa2 requiresInstanceExpansion and instanceExpander
create interfaces that nodes can implement to declare whether they
expand into instances of some sort, using the instances.Expander, and/or
whether use the instances.Expander to find instances.

included is a rough transformer implementation to remove these nodes
from the apply graph.
2020-05-28 21:30:12 -04:00
James Bardin
a2d2ce35dc 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 10:28:33 -04:00
James Bardin
d060a3d0e8 eval variables with unknown expansion data
While we don't have any expansion info during validation, we can try to
evaluate variable expressions to catch some basic errors. Do this by
creating module instance RepetitionData with unknown values. This
unfortunately will still miss the incorrect usage of count/each values,
but that would require the module call's each mode, which is not
available at this time.
2020-04-08 15:37:38 -04:00
James Bardin
c59ecac870 rename module variables and remove extra methods
The variable nodes are not only used during plan and apply, so remove
those from there names. The "plan" node is now
`nodeExpandModuleVariable` and the "apply" node is now just
`nodeModuleVariable`.

Remove unnecessary methods, as the nodeModuleVariable is no longer used
in the full graph transformations.
2020-04-08 14:41:52 -04:00
Pam Selle
6962562a78 Update diagnostic messages 2020-04-06 17:15:46 -04:00
Pam Selle
57c26fc11b Evaluate ModuleCallArguments using the appropriate ModuleInstance scope 2020-04-06 17:15:46 -04:00
James Bardin
1a1ace5930 prune unused values based on behavior
remove the hard-coded types from PruneUnusedValuesTransformer
2020-04-02 16:00:36 -04:00
James Bardin
67e06f4fbe remove more UnkeyedInstanceShim
planning variables and outputs no longer needs module instances
2020-03-10 17:25:11 -04:00
James Bardin
bd9cfca794 rename GraphNodeSubPath -> GraphNodeModuleInstance 2020-03-10 17:25:11 -04:00
James Bardin
521bdcc241 implement GraphNodeModulePath
GraphNodeModulePath is similar to GraphNodeSubPath, except that it
returns an addrs.Module rather than an addrs.ModuleInstance. This is
used by the ReferenceTransformer to connect references, when modules may
not yet be expanded.

Because references only exist within the scope of a module, we can
connect everything knowing only the module path. If the reference is to
an expanded module instance output, we can still properly order the
reference because we'll wait for the entire module to complete
evaluation.
2020-03-10 17:25:11 -04:00
Pam Selle
c249943360
Module Expansion: Part 2 (#24154)
* WIP: dynamic expand

* WIP: add variable and local support

* WIP: outputs

* WIP: Add referencer

* String representation, fixing tests it impacts

* Fixes TestContext2Apply_outputOrphanModule

* Fix TestContext2Apply_plannedDestroyInterpolatedCount

* Update DestroyOutputTransformer and associated types to reflect PlannableOutputs

* Remove comment about locals

* Remove module count enablement

* Removes allowing count for modules, and reverts the test,
while adding a Skip()'d test that works when you re-enable
the config

* update TargetDownstream signature to match master

* remove unnecessary method

Co-authored-by: James Bardin <j.bardin@gmail.com>
2020-02-24 17:42:32 -05:00
Martin Atkins
ff4ea042c2 config: Allow module authors to specify validation rules for variables
The existing "type" argument allows specifying a type constraint that
allows for some basic validation, but often there are more constraints on
a variable value than just its type.

This new feature (requiring an experiment opt-in for now, while we refine
it) allows specifying arbitrary validation rules for any variable which
can then cause custom error messages to be returned when a caller provides
an inappropriate value.

    variable "example" {
      validation {
        condition = var.example != "nope"
        error_message = "Example value must not be \"nope\"."
      }
    }

The core parts of this are designed to do as little new work as possible
when no validations are specified, and thus the main new checking codepath
here can therefore only run when the experiment is enabled in order to
permit having validations.
2020-01-10 15:23:25 -08:00
Martin Atkins
39e609d5fd vendor: switch to HCL 2.0 in the HCL repository
Previously we were using the experimental HCL 2 repository, but now we'll
shift over to the v2 import path within the main HCL repository as part of
actually releasing HCL 2.0 as stable.

This is a mechanical search/replace to the new import paths. It also
switches to the v2.0.0 release of HCL, which includes some new code that
Terraform didn't previously have but should not change any behavior that
matters for Terraform's purposes.

For the moment the experimental HCL2 repository is still an indirect
dependency via terraform-config-inspect, so it remains in our go.sum and
vendor directories for the moment. Because terraform-config-inspect uses
a much smaller subset of the HCL2 functionality, this does still manage
to prune the vendor directory a little. A subsequent release of
terraform-config-inspect should allow us to completely remove that old
repository in a future commit.
2019-10-02 15:10:21 -07:00
Martin Atkins
f14369e7fb core: Remove machinery for the "input" walk
Provider input is now longer handled with a graph walk, so the code
related to the input graph and walk are no longer needed.

For now the Input method is retained on the ResourceProvider interface,
but it will never be called. Subsequent work to revamp the provider API
will remove this method.
2018-10-16 18:49:20 -07:00
Martin Atkins
a28c93c3ce core: render variables, locals and outputs nicely in "terraform graph" 2018-10-16 18:46:46 -07:00
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
1ad97f6be8 use an EvalOpFilter for module variables
Remove the Input flag threaded through the input graph creation process
to prevent interpolation failures on module variables.
Use an EvalOpFilter instead to inset the correct EvalNode during
walkInput. Remove the EvalTryInterpolate type, and use the same
ContinueOnErr flag as the output node for consistency and to try and
keep the number possible eval node types down.
2017-10-02 16:20:29 -04:00
James Bardin
97bb7cb65c Don't allow interpolation failure to stop Input
Allow module variables to fail interpolation during input. This is OK
since they will be verified again during Plan.  Because Input happens
before Refresh, module variable interpolation can fail when referencing
values that aren't yet in the state, but are expected after Refresh.
2017-08-10 14:14:29 -04:00
Mitchell Hashimoto
5f1e6ad020
terraform: TargetsTransformer should preserve module variables
Fixes #10680

This moves TargetsTransformer to run after the transforms that add
module variables is run. This makes targeting work across modules (test
added).

This is a bug that only exists in the new graph, but was caught by a
shadow error in #10680. Tests were added to protect against regressions.
2016-12-12 20:59:14 -08:00
Mitchell Hashimoto
0d815872e1
terraform: tests for module variable node 2016-10-19 13:38:51 -07:00
Mitchell Hashimoto
3fb83f013e
terraform: depend on parent items 2016-10-19 13:38:51 -07:00
Mitchell Hashimoto
ad03a21040
terraform: rename to ModuleVariable 2016-10-19 13:38:51 -07:00