19 Commits (6440c839474f052d8997bb5cec19c2743e5108e6)

Author	SHA1	Message	Date
Pam Selle	bc55b6a28b	Use UnmarkDeepWithPaths and MarkWithPaths ... Updates existing code to use the new Value methods for unmarking/marking and removes panics/workarounds in cty marshall methods	6 years ago
Pam Selle	84d118e18f	Track sensitivity through evaluation ... Mark sensitivity on a value. However, when the value is encoded to send to the provider to produce a changeset we must remove the marks, so unmark the value and remark it with the saved path afterwards	6 years ago
James Bardin	8e3728af54	rename methods for ConfigResource changes	6 years ago
James Bardin	18ca98a064	GetConfigResourceChanges from plans ... In order to find any changes related to a particular configuration address, we need a new method to get changes to all possible instances.	6 years ago
James Bardin	323d9fb69f	plans fix	6 years ago
James Bardin	2490e6c84b	provide a method to get all modules changes ... Since modules need to be evaluated as whole objects, yet the outputs are all handled individually, we need a method to collect and return all output changes for a module from the plan, including all known module instances.	6 years ago
Martin Atkins	bbf8dacac8	plans: OutputChange.Encode must preserve Addr field	7 years ago
Martin Atkins	a43b7df282	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.	8 years ago
James Bardin	b738cdb19f	make Changes.Empty() not count NoOps ... This make the plan `Empty` concept more closely match the legacy diff behavior. Remove old unknown field from plan_test	8 years ago
Martin Atkins	d53c3d5c1b	plans: Retain output value changes for all outputs in memory ... During the plan operation we need to retain _somewhere_ the planned changes for all outputs so we can refer to them during expression evaluation. For consistency with how we handle resource instance changes, we'll keep them in the plan so we can properly retain unknown values, which cannot be written to state. As with output values in the state, only root output plans are retained in a round-trip through the on-disk plan file format, but that's okay because we can trivially re-calculate all of these during apply. We include the _root_ outputs in the plan file only because they are externally-visible side effects that ought to be included in any rendering of the plan made from the plan file for user inspection.	8 years ago
Martin Atkins	6fd82ef97e	core: Split Replace changes into separate Delete/Create changes ... Since we do our deletes using a separate graph node from all of the other actions, and a "Replace" change implies both a delete _and_ a create, we need to pretend at apply time that a single replace change was actually two separate changes. This will also early-exit eval if a destroy node finds a non-Delete change or if an apply node finds a Delete change. These should not happen in practice because we leave these nodes out of the graph when they are not needed for the given action, but we do this here for robustness so as not to have an invisible dependency between the graph builder and the eval phase.	8 years ago
Martin Atkins	1ced176fc6	plans: Track RequiredReplace as a cty.PathSet ... We were previously tracking this as a []cty.Path, but having it turned into a pathset on creation makes downstream use of it more convenient and ensures that it'll obey expected invariants like not containing the same path twice.	8 years ago
Martin Atkins	bd299b9a22	core: Re-implement EvalWriteDiff to work with new plan types	8 years ago
Martin Atkins	44bc7519a6	terraform: More wiring in of new provider types ... This doesn't actually work yet, but it builds and then panics in a pretty satisfying way.	8 years ago
Martin Atkins	dfe0988f10	plans: Record private data bytes as part of resource change ... This allows a provider to retain arbitrary extra data in the plan and make use of it during apply. The contents are not used by Terraform and never shown to the user.	8 years ago
Martin Atkins	a3403f2766	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 5861dbf3fc before, I apologize in advance to the person who inevitably just found this huge commit while spelunking through the commit history.	8 years ago
Martin Atkins	b7db32b819	plans: separate types for encoded and decoded changes ... The types here were originally written to allow us to defer decoding of object values until schemas are available, but it turns out that this was forcing us to defer decoding longer than necessary and potentially decode the same value multiple times. To avoid this, we create pairs of types to represent the encoded and decoded versions and methods for moving between them. These types are identical to one another apart from how the dynamic values are represented.	8 years ago
Martin Atkins	51aeba2cf2	plans: Record provider config address in each resource change ... This allows us to record the resource-to-provider associations we made during the plan phase and ensure that we use the same config during apply. This isn't technically necessary, since we can in principle just repeat the same matching algorithm against the config, but that algorithm is relatively complicated and so if we execute it just once during plan we remove the risk of bugs causing different decisions to be made during the apply phase. This also includes updates to the plan file format to include the provider addresses. Since we've not actually shipped any version of Terraform using our protobuf schema yet, we renumber here all of the fields after the new one to keep them incrementing consecutively. This example should not be followed after we have a released version of Terraform using this, as a courtesy to anyone trying to parse these files (even though we're not yet guaranteeing compatibility between releases).	8 years ago
Martin Atkins	7357e7f734	plans: New package for in-memory plan models ... The types in this package are intended to replace plan- and diff-related types from the "terraform" package, although those older types must remain for now so that they can be used to implement shims for older codepaths. type "Changes" is approximately equivalent to terraform.Diff, but renamed since it now describes whole objects before and after rather than an attribute-level diff as before. The term "diff" is now reserved for the visual rendition of the changes we'll display to the user, although rendering of this new Changes model is not yet implemented.	8 years ago