112 Commits (f-debugger)

Author	SHA1	Message	Date
Alisdair McDiarmid	a43b035a51	core: Reduce string allocations for addrs Equal ... Generating strings and comparing them to implement Equal is a quick and easy solution. Unfortunately when this code is in the hot path, it becomes very expensive, so this commit changes some of those instances to compare the values directly. Combined with using addr.Equal instead of checking for string equality, this makes Terraform dramatically faster for some operations, such as generating large JSON plans.	5 years ago
James Bardin	cd7fb9bd5a	catch invalidly planned attributes earlier ... Catch attributes which are planed but not computed separately to provide a clearer error to provider developers. The error conditions were previously caught, however it was unclear from the error text as to _why_ the change was an error. The statements about value inequality would be incorrect when planning no changes for a value which should not have been set in the first place.	5 years ago
James Bardin	0d63b3ec24	Merge pull request #27791 from hashicorp/jbardin/test-conformance-dynamic ... reverse call to TestConformance in objchange	5 years ago
James Bardin	22f21db229	reverse call to TestConformance in objchange ... The call to TestConformance needs to be reversed, since we want to verify that the actual value returned conforms to the planned type. While the inverse (checking that the planned value conforms to the applied type) works for everything terraform has been exposed to up until now, this fails when the planned type has dynamic attributes which are allowed to become concrete types.	5 years ago
Kristin Laemmert	8c2abbc0f0	return the properly-typed nulls, instead of empty containers, in proposedNewNestedType	5 years ago
Kristin Laemmert	77af601543	plans/objchange: extended ProposedNewObject to descend into attributes ... with NestedType objects. There are a handful of mostly cosmetic changes in this PR which likely make the diff awkward to read; I renamed several functions to (hopefully) clarifiy which funcs worked with Blocks vs other types. I also extracted some small code snippets into their own functions for reusability. The code that descends into attributes with NestedTypes is similar to the block-handling code, and differs in all the ways blocks and attributes differ: null is valid for attributes, unlike blocks which can only be present or empty.	5 years ago
Kristin Laemmert	da6ac9d6cd	plans/objchange: add handling of NestedTypes inside attributes ... - rename ProposedNewObject to ProposedNew: Now that there is an actual configschema.Object it will be clearer if the function names match the type the act upon. - extract attribute-handling logic from assertPlanValid and extend A new function, assertPlannedAttrsValid, takes the existing functionality and extends it to validate attributes with NestedTypes. The NestedType-specific handling is in assertPlannedObjectValid, which is very similar to the block-handling logic, except that nulls are a valid plan (an attribute can be null, but not a block).	5 years ago
Pam Selle	e6daf3dbf1	Unmark before ElementIterator in couldHaveUnknownBlockPlaceholder ... This is needed for cases where a variable may be fetched and become a member of a set, and thus the whole set is marked, which means ElementIterator will panic on unmarked values	5 years ago
James Bardin	a5f013830f	plans: staticcheck	6 years ago
James Bardin	fa3e534142	plans/planfile: staticcheck	6 years ago
James Bardin	913f6c2091	regenerate the plans proto with current tooling	6 years ago
James Bardin	5f4ff0e8be	don't render plan for module outputs ... Module outputs should not trigger plan rendering.	6 years ago
James Bardin	ef086399f9	compare empty strings as null in sets ... The Legacy SDK cannot handle missing strings from objects in sets, and will insert an empty string when planning the missing value. This subverts the `couldHaveUnknownBlockPlaceholder` check, and causes errors when `dynamic` is used with NestingSet blocks. We don't have a separate codepath to handle the internals of AssertObjectCompatible differently for the legacy SDK, but we can treat empty strings as null strings within set objects to avoid the failed assertions.	6 years ago
James Bardin	77af322c1c	handle non-null, but empty NestingMap in a set	6 years ago
James Bardin	b59c64245b	refactor ifs to reduce indentation	6 years ago
James Bardin	f128b8c4fa	take dynamic types into account when comparing set ... If a NestingList or NestingMap contains a dynamic type, they must be handled as a cty.Tuple and cty.Object respectively, because the elements may not have precisely matching types.	6 years ago
Alexander Ovechkin	d7db008df2	added empty list test case	6 years ago
Alexander Ovechkin	8fbb4d0163	Converting ListVal to ListVal instead of TupleVal in setElementCompareValue	6 years ago
Pam Selle	fcae49611c	Merge pull request #26555 from hashicorp/pselle/sensitive-var-value-compat ... Avoid disclosing values in errors on marked vals	6 years ago
James Bardin	5eca0788c6	rely solely on the plan changes for outputs ... Now that outputs changes are tracked in full, we can remove the comparisons with the prior state and use the planned changes directly.	6 years ago
Pam Selle	da4ddd0160	Avoid disclosing values in errors on marked vals ... AssertObjectCompatible is a special case that will expose Go string values of values unless otherwise stopped. This adds that check.	6 years ago
James Bardin	c48af3f18b	Merge pull request #26470 from hashicorp/jbardin/inverse-destroy-references ... Allow special-case evaluation of instances pending deletion.	6 years ago
James Bardin	0c72c6f144	s/FullDestroy/IsFullDdestroy/	6 years ago
Kristin Laemmert	3933cbd491	remove LegacyProvider (#26433)	6 years ago
Pam Selle	f35b530837	Update compatibility checks for blocks to not use marks ... Remove marks for object compatibility tests to allow apply to continue. Adds a block to the test provider to use in testing, and extends the sensitivity apply test to include a block	6 years ago
James Bardin	fa8f8df7b6	add ChangesSync.FullDestroy ... In order to handle various edge cases during a full destroy, add FullDestroy to the synchronized changes so we can attempt to deduce if the plan was created from `terraform destroy`. It's possible that the plan was created by removing all resourced from the configuration, but in that case the end result is the same. Any of the edge cases with provider or destroy provisioner configurations would not apply, since there would not be any configuration references to resolve.	6 years ago
Pam Selle	0b3c21a3eb	Support lists of deeply marked values	6 years ago
Pam Selle	3dde9efc75	Support list diffs with sensitivity ... Adds support for specialized diffs with lists	6 years ago
James Bardin	8cef62e455	add state to plans.Plan ... Since the refreshed state is now an artifact of the plan process, it makes sense to add it to the Plan type, rather than adding an additional return value to the Context.Plan method.	6 years ago
Pam Selle	20ee878d0e	Updates and improvements to comments	6 years ago
Pam Selle	5b0b1a13a5	Update object compatible check to unmark ... The hack approach appears consistent, as we can remove marks before calling the value validation	6 years ago
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	6c129a921b	Unmark/remark in apply process to allow apply	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	2b4101fdff	Unknown set blocks with dynamic may have 0 elems ... The couldHaveUnknownBlockPlaceholder helper was added to detect when a set block has a placeholder for an unknown number of values. This worked fine when the number increased from 1, but we were still attempting to validate the unknown placeholder against the empty set when the final count turned out to be 0. Since we can't differentiate the unknown dynamic placeholder value from an actual set value, we have to skip that object's validation altogether.	6 years ago
Chris Stephens	2dd64a7816	plans: Update error message for apply validation (#21312) ... * Update error message for apply validation Add a hint that the validation failure has occurred at the root of the resource schema to the error message. This is because the root resource has an empty path when being validated and the path is being relied upon to provide context into the error message.	6 years ago
Martin Atkins	31a4b44d2e	backend/local: treat output changes as side-effects to be applied ... This is a baby-step towards an intended future where all Terraform actions which have side-effects in either remote objects or the Terraform state can go through the plan+apply workflow. This initial change is focused only on allowing plan+apply for changes to root module output values, so that these can be written into a new state snapshot (for consumption by terraform_remote_state elsewhere) without having to go outside of the primary workflow by running "terraform refresh". This is also better than "terraform refresh" because it gives an opportunity to review the proposed changes before applying them, as we're accustomed to with resource changes. The downside here is that Terraform Core was not designed to produce accurate changesets for root module outputs. Although we added a place for it in the plan model in Terraform 0.12, Terraform Core currently produces inaccurate changesets there which don't properly track the prior values. We're planning to rework Terraform Core's evaluation approach in a forthcoming release so it would itself be able to distinguish between the prior state and the planned new state to produce an accurate changeset, but this commit introduces a temporary stop-gap solution of implementing the logic up in the local backend code, where we can freeze a snapshot of the prior state before we take any other actions and then use that to produce an accurate output changeset to decide whether the plan has externally-visible side-effects and render any changes to output values. This temporary approach should be replaced by a more appropriately-placed solution in Terraform Core in a release, which should then allow further behaviors in similar vein, such as user-visible drift detection for resource instances.	6 years ago
James Bardin	e690fa1363	Merge pull request #24904 from hashicorp/jbardin/plan-data-sources ... Evaluate data sources in plan when necessary	6 years ago
James Bardin	8e3728af54	rename methods for ConfigResource changes	6 years ago
Kazuki Higashiguchi	7e46b6b9e7	fix typo ResourceInstancChange to ResourceInstanceChange	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
James Bardin	e13eecbc5b	finish provider ModuleInstance replacement	6 years ago
Kristin Laemmert	47a16b0937	addrs: embed Provider in AbsProviderConfig instead of Type ... a large refactor to addrs.AbsProviderConfig, embedding the addrs.Provider instead of a Type string. I've added and updated tests, added some Legacy functions to support older state formats and shims, and added a normalization step when reading v4 (current) state files (not the added tests under states/statefile/roundtrip which work with both current and legacy-style AbsProviderConfig strings). The remaining 'fixme' and 'todo' comments are mostly going to be addressed in a subsequent PR and involve looking up a given local provider config's FQN. This is fine for now as we are only working with default assumption.	6 years ago
Martin Atkins	8b511524d6	Initial steps towards AbsProviderConfig/LocalProviderConfig separation (#23978) ... * Introduce "Local" terminology for non-absolute provider config addresses In a future change AbsProviderConfig and LocalProviderConfig are going to become two entirely distinct types, rather than Abs embedding Local as written here. This naming change is in preparation for that subsequent work, which will also include introducing a new "ProviderConfig" type that is an interface that AbsProviderConfig and LocalProviderConfig both implement. This is intended to be largely just a naming change to get started, so we can deal with all of the messy renaming. However, this did also require a slight change in modeling where the Resource.DefaultProviderConfig method has become Resource.DefaultProvider returning a Provider address directly, because this method doesn't have enough information to construct a true and accurate LocalProviderConfig -- it would need to refer to the configuration to know what this module is calling the provider it has selected. In order to leave a trail to follow for subsequent work, all of the changes here are intended to ensure that remaining work will become obvious via compile-time errors when all of the following changes happen: - The concept of "legacy" provider addresses is removed from the addrs package, including removing addrs.NewLegacyProvider and addrs.Provider.LegacyString. - addrs.AbsProviderConfig stops having addrs.LocalProviderConfig embedded in it and has an addrs.Provider and a string alias directly instead. - The provider-schema-handling parts of Terraform core are updated to work with addrs.Provider to identify providers, rather than legacy strings. In particular, there are still several codepaths here making legacy provider address assumptions (in order to limit the scope of this change) but I've made sure each one is doing something that relies on at least one of the above changes not having been made yet. * addrs: ProviderConfig interface In a (very) few special situations in the main "terraform" package we need to make runtime decisions about whether a provider config is absolute or local. We currently do that by exploiting the fact that AbsProviderConfig has LocalProviderConfig nested inside of it and so in the local case we can just ignore the wrapping AbsProviderConfig and use the embedded value. In a future change we'll be moving away from that embedding and making these two types distinct in order to represent that mapping between them requires consulting a lookup table in the configuration, and so here we introduce a new interface type ProviderConfig that can represent either AbsProviderConfig or LocalProviderConfig decided dynamically at runtime. This also includes the Config.ResolveAbsProviderAddr method that will eventually be responsible for that local-to-absolute translation, so that callers with access to the configuration can normalize to an addrs.AbsProviderConfig given a non-nil addrs.ProviderConfig. That's currently unused because existing callers are still relying on the simplistic structural transform, but we'll switch them over in a later commit. * rename LocalType to LocalName Co-authored-by: Kristin Laemmert <mildwonkey@users.noreply.github.com>	6 years ago
Kristin Laemmert	6541775ce4	addrs: roll back change to Type field in ProviderConfig (#23937)	6 years ago
Kristin Laemmert	e3416124cc	addrs: replace "Type string" with "Type Provider" in ProviderConfig ... * huge change to weave new addrs.Provider into addrs.ProviderConfig * terraform: do not include an empty string in the returned Providers / Provisioners - Fixed a minor bug where results included an extra empty string	7 years ago
Radek Simko	7860f55e4f	Version tools per Go convention under tools.go	7 years ago
Radek Simko	3d94baecf6	Regenerate protobuf files under latest versions ... Used protobuf 3.9.1 with protoc-gen-go 1.3.2	7 years ago