42 Commits (94de72c63834acea811c27a585c19eae29374a4b)

Author	SHA1	Message	Date
Martin Atkins	4cffff24b1	core: Report reason for deferring data read until apply ... We have two different reasons why a data resource might be read only during apply, rather than during planning as usual: the configuration contains unknown values, or the data resource as a whole depends on a managed resource which itself has a change pending. However, we didn't previously distinguish these two in a way that allowed the UI to describe the difference, and so we confusingly reported both as "config refers to values not yet known", which in turn led to a number of reasonable questions about why Terraform was claiming that but then immediately below showing the configuration entirely known. Now we'll use our existing "ActionReason" mechanism to tell the UI layer which of the two reasons applies to a particular data resource instance. The "dependency pending" situation tends to happen in conjunction with "config unknown", so we'll prefer to refer that the configuration is unknown if both are true.	4 years ago
James Bardin	7da52d94f2	Merge pull request #30900 from hashicorp/jbardin/replace-triggered-by ... Configurable instance replacement via lifecycle `replace_triggered_by`	4 years ago
James Bardin	0fe38fba6c	prevent unsynchronized output changes access ... The raw plan output changes were stored in the output exec node, when they should have instead been fetch lazily through the context via the synchronized ChangesSync value.	4 years ago
James Bardin	3a0a019521	round-trip replace triggers	4 years ago
James Bardin	54c1791a1b	add triggers reason to plan proto	4 years ago
James Bardin	e4c4dcbd14	add ResourceInstanceReplaceByTriggers	4 years ago
James Bardin	91121aa856	limit replace_triggered_by to same module instance ... replace_triggered_by references are scoped to the current module, so we need to filter changes for the current module instance. Rather than creating a ConfigResource and filtering the result, make a Changes.InstancesForAbsResource method to get only the AbsResource changes.	4 years ago
Eng Zer Jun	fedd315275	test: use `T.TempDir` to create temporary test directory (#30803) ... This commit replaces `ioutil.TempDir` with `t.TempDir` in tests. The directory created by `t.TempDir` is automatically removed when the test and all its subtests complete. Prior to this commit, temporary directory created using `ioutil.TempDir` needs to be removed manually by calling `os.RemoveAll`, which is omitted in some tests. The error handling boilerplate e.g. defer func() { if err := os.RemoveAll(dir); err != nil { t.Fatal(err) } } is also tedious, but `t.TempDir` handles this for us nicely. Reference: https://pkg.go.dev/testing#T.TempDir Signed-off-by: Eng Zer Jun <engzerjun@gmail.com>	4 years ago
Alisdair McDiarmid	c5d10bdef1	core: Store condition block results in plan ... In order to include condition block results in the JSON plan output, we must store them in the plan and its serialization. Terraform can evaluate condition blocks multiple times, so we must be able to update the result. Accordingly, the plan.Conditions object is a map with keys representing the condition block's address. Condition blocks are not referenceable in any other context, so this address form cannot be used anywhere in the configuration. The commit includes a new test case for the JSON output of a refresh-only plan, which is currently the only way for a failing condition result to be rendered through this path.	4 years ago
James Bardin	773f5b02ec	round-trip relevant attributes through planfile	4 years ago
James Bardin	e2b74247f2	track contributing instances ... Track individual instance drift rather than whole resources which contributed to the plan. This will allow the output to be more precise, and we can still use NoKey instances as a proxy for containing resources when needed.	4 years ago
James Bardin	0e7cec83db	decode change before creating diff ... This is functionally equivalent, but will allow us to filter the change values directly for reduced drift output.	4 years ago
James Bardin	c02e8bc5b3	change plan to store individual relevant attrs ... Storing individual contributing attributes will allow finer tuning of the plan rendering. add contributing to outputs	4 years ago
James Bardin	6d33de8a9d	fixup analysis calls from rebase	4 years ago
Martin Atkins	2e6b6e9a6b	go.mod: go get google.golang.org/protobuf@v1.27.1	5 years ago
James Bardin	aece887a85	Merge pull request #29701 from hashicorp/jbardin/proposed-new-null-objs ... objchange: fix ProposedNew from null objects	5 years ago
James Bardin	58d85fcc2e	add test for planing unknown data source values	5 years ago
James Bardin	18d354223e	objchange: fix ProposedNew from null objects ... The codepath for AllAttributesNull was not correct for any nested object types with collections, and should create single null values for the correct NestingMode rather than a single object with null attributes. Since there is no reason to descend into nested object types to create nullv alues, we can drop the AllAttributesNull function altogether and create null values as needed during ProposedNew. The corresponding AllBlockAttributesNull was only called internally in 1 location, and simply delegated to schema.EmptyValue. We can reduce the package surface area by dropping that function too and calling EmptyValue directly.	5 years ago
Martin Atkins	702413702c	plans/planfile: Include dependency locks in saved plan files ... We recently removed the legacy way we used to track the SHA256 hashes of individual provider executables as part of a plans.Plan, because these days we want to track the checksums of entire provider packages rather than just the executable. In order to achieve that new goal, we can save a copy of the dependency lock information inside the plan file. This follows our existing precedent of using exactly the same serialization formats we'd normally use for this information, and thus we can reuse the existing models and serializers and be confident we won't lose any detail in the round-trip. As of this commit there's not yet anything actually making use of this mechanism. In a subsequent commit we'll teach the main callers that write and read plan files to include and expect (respectively) dependency information, verifying that the available providers still match by the time we're applying the plan.	5 years ago
Martin Atkins	6a98e4720c	plans/planfile: Create takes most arguments via a struct type ... Previously the planfile.Create function had accumulated probably already too many positional arguments, and I'm intending to add another one in a subsequent commit and so this is preparation to make the callsites more readable (subjectively) and make it clearer how we can extend this function's arguments to include further components in a plan file. There's no difference in observable functionality here. This is just passing the same set of arguments in a slightly different way.	5 years ago
Martin Atkins	8d193ad268	core: Simplify and centralize plugin availability checks ... Historically the responsibility for making sure that all of the available providers are of suitable versions and match the appropriate checksums has been split rather inexplicably over multiple different layers, with some of the checks happening as late as creating a terraform.Context. We're gradually iterating towards making that all be handled in one place, but in this step we're just cleaning up some old remnants from the main "terraform" package, which is now no longer responsible for any version or checksum verification and instead just assumes it's been provided with suitable factory functions by its caller. We do still have a pre-check here to make sure that we at least have a factory function for each plugin the configuration seems to depend on, because if we don't do that up front then it ends up getting caught instead deep inside the Terraform runtime, often inside a concurrent graph walk and thus it's not deterministic which codepath will happen to catch it on a particular run. As of this commit, this actually does leave some holes in our checks: the command package is using the dependency lock file to make sure we have exactly the provider packages we expect (exact versions and checksums), which is the most crucial part, but we don't yet have any spot where we make sure that the lock file is consistent with the current configuration, and we are no longer preserving the provider checksums as part of a saved plan. Both of those will come in subsequent commits. While it's unusual to have a series of commits that briefly subtracts functionality and then adds back in equivalent functionality later, the lock file checking is the only part that's crucial for security reasons, with everything else mainly just being to give better feedback when folks seem to be using Terraform incorrectly. The other bits are therefore mostly cosmetic and okay to be absent briefly as we work towards a better design that is clearer about where that responsibility belongs.	5 years ago
Martin Atkins	a1a713cf28	core: Report ActionReasons when we plan to delete "orphans" ... There are a few different reasons why a resource instance tracked in the prior state might be considered an "orphan", but previously we reported them all identically in the planned changes. In order to help users understand the reason for a surprising planned delete, we'll now try to specify an additional reason for the planned deletion, covering all of the main reasons why that could happen. This commit only introduces the new detail to the plans.Changes result, though it also incidentally exposes it as part of the JSON plan result in order to keep that working without returning errors in these new cases. We'll expose this information in the human-oriented UI output in a subsequent commit.	5 years ago
Alisdair McDiarmid	c4688345a1	plans: Add resource drift to the plan file format	5 years ago
Alisdair McDiarmid	bebf1ad23a	core: Compute resource drift after plan walk ... Rather than delaying resource drift detection until it is ready to be presented, here we perform that computation after the plan walk has completed. The resulting drift is represented like planned resource changes, using a slice of ResourceInstanceChangeSrc values.	5 years ago
James Bardin	331dc8b14c	handle empty containers in ProposedNew NestedTypes ... Empty containers of NestedTypes were not handled in ProposedNew, causing plans to be submitted with null values where there was configuration present.	5 years ago
James Bardin	8ed9a270e5	Merge pull request #29559 from hashicorp/jbardin/optional-attrs ... Prevent `ObjectWithOptionalAttrs` from escaping	5 years ago
James Bardin	43123d284e	optional attrs should not be in ProposedNew	5 years ago
James Bardin	782132da33	remove incorrect computed check ... The config is already validated, and does not need to be checked in AssertPlanValid. Add some more coverage for plan validation.	5 years ago
Alisdair McDiarmid	29999c1d6f	command: Render "moved" annotations in plan UI ... For resources which are planned to move, render the previous run address as additional information in the plan UI. For the case of a move-only resource (which otherwise is unchanged), we also render that as a planned change, but without any corresponding action symbol. If all changes in the plan are moves without changes, the plan is no longer considered "empty". In this case, we skip rendering the action symbols in the UI.	5 years ago
James Bardin	7c02ef6220	Merge pull request #29482 from hashicorp/jbardin/computed-obj-attrs ... Computed values within nested object types in `AssertPlanValid`	5 years ago
James Bardin	f195ce7fd4	remove temp test	5 years ago
Martin Atkins	22b36d1f4c	Field for the previous address of each resource instance in the plan ... In order to expose the effect of any relevant "moved" statements we dealt with prior to creating the plan, we'll record with each ResourceInstanceChange both is current address and the address it was tracked at for the previous run. To save consumers of these objects from having to special-case the situation where there _was_ no previous run (e.g. because this is a Create change), we'll just pretend the previous run address was the same as the current address in that case, the same as for an update without any renaming in effect. This includes a breaking change to the plan file format, but one that doesn't require a version number increment because there is no ambiguity between the two formats and so mismatched parsers will already fail with an error message. As of this commit we've just added the new field but not yet populated it with any useful information: it always just matches Addr. A future commit will wire this up to the result of applying the moves so that we can populate it correctly. We also don't yet expose this new information anywhere in the UI layer.	5 years ago
James Bardin	ea68d79ea2	nested object values can be computed ... While blocks were not allowed to be computed by the provider, nested objects can be. Remove the errors regarding blocks and verify unknown values are valid.	5 years ago
James Bardin	903797084a	objects vs maps in nested object types ... When using NestedMap objects, unify the codepath for both maps and objects as they may be interchangeable.	5 years ago
James Bardin	7ca6be8285	correctly verify planned nested object values ... The validation for nested object types with computed attributes was using the incorrect function call.	5 years ago
Martin Atkins	ce96d82de0	build: Centralize our protobuf compilation steps ... We have a few different .proto files in this repository that all need to get recompiled into .pb.go files each time we change them, but we were previously handling that with some scripts that just assumed that protoc and the relevant plugins were already installed on the system somewhere, at the right versions. In practice we've been constantly flopping between different versions of these tools due to folks having different versions installed in their development environments. In particular, the state of the .pb.go files in the prior commit wasn't reproducible by any single version of the tools because they've all slightly diverged from one another. In the interests of being more consistent here and avoiding accidental inconsistencies, we'll now centralize the protocol buffer compile steps all into a single tool that knows how to fetch and install the expected versions of the various tools we need and then run those tools with the right options to get a stable result. If we want to upgrade to either a newer protoc or a newer protoc-gen-go in future then we'll do that in a central location and update all of the .pb.go files at the same time, so that we're always consistently tracking the same version of protocol buffers everywhere. While doing this I attempted to keep as close as possible to the toolchain we'd most recently used, but since they were not consistent with each other they've now all changed which version numbers they record at minimum, and the planproto stub in particular now also has a slightly different descriptor serialization but is otherwise offering the same API.	5 years ago
James Bardin	da007517b0	handle null NestingSingle values ... Null NestingSingle attributes were not being handled in ProposedNew	5 years ago
Kristin Laemmert	0d80a74539	configs/configschema: fix missing "computed" attributes from NestedObject's ImpliedType (#29172) ... * configs/configschema: fix missing "computed" attributes from NestedObject's ImpliedType listOptionalAttrsFromObject was not including "computed" attributes in the list of optional object attributes. This is now fixed. I've also added some tests and fixed some panics and otherwise bad behavior when bad input is given. One natable change is in ImpliedType, which was panicking on an invalid nesting mode. The comment expressly states that it will return a result even when the schema is inconsistent, so I removed the panic and instead return an empty object.	5 years ago
James Bardin	d9dfd451ea	update to use typed sensitive marks	5 years ago
James Bardin	b7f8ef4dc6	handle unexpected changes to unknown block ... An unknown block represents a dynamic configuration block with an unknown for_each value. We were not catching the case where a provider modified this value unexpectedly, which would crash with block of type NestingList blocks where the config value has no length for comparison.	5 years ago
Martin Atkins	f40800b3a4	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.	5 years ago
Martin Atkins	034e944070	Move plans/ to internal/plans/ ... 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.	5 years ago