This project is mirrored from https://:*****@github.com/hashicorp/terraform.git.
Pull mirroring failed .
Repository mirroring has been paused due to too many failed attempts. It can be resumed by a project maintainer.
Repository mirroring has been paused due to too many failed attempts. It can be resumed by a project maintainer.
- 26 Jun, 2018 40 commits
-
-
Martin Atkins authored
The existing cty packages were already at the latest version, but we were not yet vendoring the msgpack package. This also imports some dependencies from: github.com/vmihailenco/msgpack
-
Martin Atkins authored
-
Martin Atkins authored
This is a wrapper around State that is able to perform higher-level manipulations (at the granularity of the entire state) in a concurrency-safe manner, using the lower-level APIs exposed by State and all of the types it contains. The granularity of a SyncState operation roughly matches the granularity off a state-related EvalNode in the "terraform" package, performing a sequence of more primitive operations while guaranteeing atomicity of the entire change. As a compromise for convenience of usage, it's still possible to access the individual state data objects via this API, but they are always copied before returning to ensure that two distinct callers cannot have data races. Callers should access the most granular object possible for their operation.
-
Martin Atkins authored
This idea of a "state manager" was previously modelled via the confusingly-named state.State interface, which we've been calling a "state manager" only in some local variable names in situations where there were also *terraform.State variables. As part of reworking our state models to make room for the new type system, we also need to change what was previously the state.StateReader interface. Since we've found the previous organization confusing anyway, here we just copy all of those interfaces over into statemgr where we can make the relationship to states.State hopefully a little clearer. This is not yet a complete move of the functionality from "state", since we're not yet ready to break existing callers. In a future commit we'll turn the interfaces in the old "state" package into aliases of the interfaces in this package, and update all the implementers of what will by then be statemgr.Reader to use *states.State instead of *terraform.State. This also includes an adaptation of what was previously state.LocalState into statemgr.FileSystem, using the new state serialization functionality from package statefile instead of the old terraform.ReadState and terraform.WriteState.
-
Martin Atkins authored
Whereas the parent directory "states" contains the models that represent state in memory, this package's responsibility is in serializing a subset of that data to a JSON-based file format and then reloading that data back into memory later. For reading, this package supports state file formats going back to version 1, using lightly-adapted versions of the migration code previously used in the "terraform" package. State data is upgraded to the latest version step by step and then transformed into the in-memory state representation, which is distinct from any of the file format structs in this package to enable these to evolve separately. For writing, only the latest version (4) is supported, which is a new format that is a slightly-flattened version of the new in-memory state models introduced in the prior commit. This format retains the outputs from only the root module and it flattens out the module and instance parts of the hierarchy by including the identifiers for these inside the child object. The loader then reconstructs the multi-layer structure we use for more convenient access in memory. For now, the only testing in this package is of round-tripping different versions of state through a read and a write, ensuring the output is as desired. This exercises all of the reading, upgrading, and writing functions but should be augmented in later commits to improve coverage and introduce more focused tests for specific parts of the functionality.
-
Martin Atkins authored
Our previous state models in the "terraform" package had a few limitations that are addressed here: - Instance attributes were stored as map[string]string with dot-separated keys representing traversals through a data structure. Now that we have a full type system, it's preferable to store it as a real data structure. - The existing state structures skipped over the "resource" concept and went straight to resource instance, requiring heuristics to decide whether a particular resource should appear as a single object or as a list of objects when used in configuration expressions. - Related to the previous point, the state models also used incorrect terminology where "ResourceState" was really a resource instance state and "InstanceState" was really the state of a particular remote object associated with an instance. These new models use the correct names for each of these, introducing the idea of a "ResourceInstanceObject" as the local record of a remote object associated with an instance. This is a first pass at fleshing out a new model for state. Undoubtedly there will be further iterations of this as we work on integrating these new models into the "terraform" package. These new model types no longer serve double-duty as a description of the JSON state file format, since they are for in-memory use only. A subsequent commit will introduce a separate package that deals with persisting state to files and reloading those files later.
-
Martin Atkins authored
Our main "parse" methods in this package work with hcl.Traversals, but we're gradually adding helpers to parse these directly froms strings since the visual noise of doing the traversal parse first is inconvenient in situations where addresses are coming from non-config locations where no source information is available anyway.
-
Martin Atkins authored
This can be used to sort lists of resource instance and module instance addresses, such as in a rendered plan.
-
Kristin Laemmert authored
-
Kristin Laemmert authored
-
Kristin Laemmert authored
-
Kristin Laemmert authored
-
Kristin Laemmert authored
-
Kristin Laemmert authored
-
Martin Atkins authored
Because of the size of some of these files, automatic format-on-save was implicitly disabled in my editor, which I didn't notice before committing.
-
James Bardin authored
Otherwsie relative addresses may collide and close the incorrect provider.
-
James Bardin authored
This makes sure the graph is complete for validation
-
Martin Atkins authored
In the heirarchy, both "Terraform Language" and "Functions" are "up" from the individual function reference pages, so we'll class them as such to use the back-facing arrow instead of the forward-facing arrow.
-
Martin Atkins authored
I missed these on the first pass because in the legacy function table they are, for some reason, added in a different place than the others.
-
Martin Atkins authored
We historically tolerated this, so we need to tolerate it here too in order to work correctly with existing provider code.
-
Martin Atkins authored
-
Martin Atkins authored
These are no longer correct due to the input walk being removed in an earlier commit.
-
Martin Atkins authored
This was testing that returning a number as an output would be reported as an error, but that is intentionally allowed now.
-
Martin Atkins authored
I updated the "Variables" map incorrectly in earlier commit 10fe50bbdb while making bulk updates to get the tests compiling again with the changed underlying APIs. The original value here was "bar", incorrectly changed to "foo" in that commit. Here we return it back to "bar".
-
James Bardin authored
DynamicExpand also needs to add the provisioner schemas to make sure all references are found in the subgraph.
-
Martin Atkins authored
We only support provider input for the root module. This is already checked in ProviderInput, but was not checked in SetProviderInput. We can't actually do anything particularly clever with an invalid call here, but we will at least generate a WARN log to help with debugging. Also need to update TestBuiltinEvalContextProviderInput to expect this new behavior of ignoring input for non-root modules.
-
Martin Atkins authored
This test is now failing due to the fact that WritePlan is currently disabled pending a rewrite. This will be addressed in a subsequent commit.
-
Martin Atkins authored
Now that we fetch schemas during NewContext, we need to configure the mock GetSchema method before constructing the context.
-
James Bardin authored
-
James Bardin authored
-
Martin Atkins authored
The prior commit changed the schema-access model so that all schemas are fetched up front during context creation and are then readily available for use throughout graph building and evaluation. As a result, we no longer need to create dependency edges to a provider when one of its resources is referenced by another node, and so the ProviderTransformer needs only to worry about direct ownership dependencies. This also avoids the need for us to run AttachSchemaTransformer twice, since ProviderTransformer no longer needs schema and we can therefore defer attaching until just before ReferenceTransformer, when all of the referencable and referencing nodes are already present in the graph.
-
Martin Atkins authored
-
Martin Atkins authored
We now fetch all of the necessary schemas during context creation, so we can just thread that repository of schemas through into EvalContext and Evaluator and access the schemas as needed without any further fetching. This requires updating a few tests to have a valid Provider address in their state objects, because we need that in order to trigger the loading of the relevant schema.
-
James Bardin authored
-
Martin Atkins authored
This test depends on having a correct schema, so we'll specify the minimum schema for its fixture inline here rather than using the superset schema returned by testProvider.
-
Martin Atkins authored
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.
-
James Bardin authored
The instnace info ID has changed, and no longer reflects the type of node. Record the state to determine apply order for this test.
-
James Bardin authored
The test fixture no longer changes the ID on updates.
-
James Bardin authored
Add a graphNodeAttachDestroy interface, so destroy nodes can be attached to their companion create node. The creator can then reference the CreateBeforeDestroy status of the destroyer, determining if the current state needs to be replaced or deposed. This is needed when a node is forced to become CreateBeforeDestroy by a dependency rather than the config, since because the config is immutable, only the destroyer is aware that it has been forced CreateBeforeDestroy.
-
Martin Atkins authored
The earlier change 5f07201a made it so that the state is always rewritten by EvalDiffDestroy, but that was too disruptive to other users of EvalDiffDestroy. Now we follow the lead of EvalDiff and have a separate pointer for the _output_ state, which allows the caller to opt in to having its state pointer updated to reflect the new (nil) state. NodePlannableResourceInstanceOrphan is the only caller that currently opts in to this, since that was the focus of 5f07201a. We may need to make a similar change to other plannable resource destroy nodes, but we'll wait to see if that needs to be done in a subsequent commit.
-