terraform

Commit Graph

Author	SHA1	Message	Date
Radek Simko	0fe906fa8c	make copyrightfix	2 months ago
Sarah French	fd7f25120b	PSS: Allow pluggable state store configuration to be read from a plan file (#37957 ) * feat: Allow reading state store configuration from a planfile and using it to prepare a Local backend that uses the state store * test: Assert that we can get and use state store configuration from a plan file * test: Add integration test showing that an apply command can use a plan file to configure and use a state store * test: Add E2E test showing pluggable state storage being used with the full init-plan-apply workflow * feat: A plan file will report the state storage provider among its required providers, if PSS is in use. See the code comment added in this commit. This addition does not impact an apply command as the missing provider will be detected before this code is executed. However I'm making this change so that the method is still accurate is being able to return a complete list of providers needed by the plan. * fix: Include error messages when there is a problem parsing provider or state store config when getting a backend from a planfile * feat: Add trace logs to BackendForLocalPlan indicating when the provider is launched and the state store is configured * chore: Small grammar change in error diagnostic * refactor: Remove suggestions when the plan's state store doesn't match the implementations in the provider * test: Add test coverage of what happens when the contents of a plan file using PSS doesn't match the resources available in the project	4 months ago
Sarah French	9fb91c2229	PSS: Refactor Plan struct to reference `Backend` and `StateStore` via pointers, update calling code (#37946 ) * refactor: Update Plan struct's Backend field to be a pointer * fix: Add some refactorings or protections against nil pointers when accessing the Backend field on a Plan struct * refactor: Update Plan struct's StateStore field to be a pointer, update a nil check in calling code.	5 months ago
Daniel Schmidt	ad4371342f	track partial expanded action invocations through deferred action invocation like we do it for resources just simpler because we don't have layered addrs maps	8 months ago
Daniel Schmidt	dffeeec81e	partially expand triggers as well	8 months ago
Liam Cervante	866363ffff	actions: add invoke nodes to the graph (#37521 ) * actions: add invoke graph nodes * fix small bugs * add additional tests * remove whitespace * fix copyright headers * go generate * address comments	8 months ago
Daniel Schmidt	14c83aa7ee	allow reporting action invocations as deferred	8 months ago
Daniel Schmidt	c2b35e7ee7	remove duplicate place to store action invocations from plan	9 months ago
Kristin Laemmert	9256074c43	Actions in plan/changes (#37320 ) * Add actions to the plans and change * jsonplan - ignoring LinkedResources for now, those are not in the MVP * pausing here: we'll work on the plan rendering later	9 months ago
Sarah French	d02a1ed1b7	PSS: Make the state storage provider's config stateful (backend state, planfiles) (#37286 )	9 months ago
Sarah French	2349481b23	Update data stored in plan files to enable using PSS with saved plans (#37246 ) * Implement `ForPlan` method on `StateStoreConfigState`, add `Planner` interface * Rename `ForPlan` method to `Plan` * Allow plan files to contain information about state stores * Add code needed for representing a state store in the Plan struct, which is used when handling plan files * Add ability to read/write either a backend or state store's data in a plan file. Add some test coverage. * Update plan's `ProviderAddrs` method to include the provider used for PSS, if present * Split interfaces * Apply feedback from code review * Refactor `SetVersion` to use appropriate constructor * Split `ProviderAddrs` method test into two * Fix method call after rename * Fix test * Remove change to `(p Plan) ProviderAddrs()` We may re-add this when we implement PSS for use during apply commands with plan files Remove changes to test, now that the plan doesn't report the provider used for PSS anymore.	10 months ago
James Bardin	807e084130	final renaming for function results	11 months ago
James Bardin	a6ec17cb77	rename function results table Remove "provider" from the function results fields since it's not going to be exclusively used for providers any longer.	11 months ago
James Bardin	d016070564	move function results hashing to lang We need to abstract the function results verification to use internally too, so start by moving it out of the providers code.	11 months ago
James Bardin	bc750192e4	POC for always using decoded changes in core We should not need to encode and decode change values within core, since the encoded version is only technically needed for serialization. This pattern stems from the conversion to current changes system, but back then we did not have easy access to the correct schemas at the time to encode and decode the entire set of changes. Moving the core handling of changes to only use the decoded values will drastically improve evaluation efficiency, removing a round trip through encoded values for every resource reference.	2 years ago
Martin Atkins	641219bd19	plans: Track input variables that must be re-supplied during apply We'll use this to track what subset of the ephemeral input variables were set in the planning options, and which ones must therefore be re-supplied in the apply phase options. This new plan field is not yet populated anywhere. The uses of this will follow in subsequent commits.	2 years ago
Liam Cervante	bba161ce6b	terraform test: remove planned state from plan (#35049 )	2 years ago
Liam Cervante	28797e7938	Add the deferred changes into the plan (#34946 ) * Add the deferred changes into the plan * add copywrite headers	2 years ago
Martin Atkins	884e1fb2a4	terraform: Plans can be "complete" and "applyable" These ideas are both already implied by some logic elsewhere in the system, but until now we didn't have the decision logic centralized in a single place that could therefore evolve over time without necessarily always updating every caller together. We'll now have the modules runtime produce its own boolean ruling about each characteristic, which callers can rely on for the mechanical decision-making of whether to offer the user an "approve" prompt, and whether to remind the user after apply that it was an incomplete plan that will probably therefore need at least one more plan/apply round to converge. The "Applyable" flag directly replaces the previous method Plan.CanApply, with equivalent logic. Making this a field instead of a method means that we can freeze it as part of a saved plan, rather than recalculating it when we reload the plan, and we can export the field value in our export formats like JSON while ensuring it'll always be consistent with what Terraform is using internally. Callers can (and should) still use other context in the plan to return more tailored messages for specific situations they already know about that might be useful to users, but with these flags as a baseline callers can now just fall back to a generic presentation when encountering a situation they don't yet understand, rather than making the wrong decision and causing something strange to happen. That is: a lack of awareness of a new rule will now cause just a generic message in the UI, rather than incorrect behavior. This commit mostly just deals with populating the flags, and then all of the direct consequences of that on our various tests. Further changes to actually make use of these flags elsewhere in the system will follow in later commits, both in this repository and in other repositories.	2 years ago
James Bardin	bc945f22eb	Merge pull request #34515 from hashicorp/jbardin/provider-function-validation Add validation for provider function results	2 years ago
James Bardin	a3aa517589	store and verify provider functions calls in plan Store the hashed function calls within the plan file, so that Terraform can validate the results during apply as well. The error won't be as good, since we don't have access to the prior results to help debugging, but it is very helpful to indicate when a function returned an incorrect result rather than show that the resource attempted to apply a different value from what was originally planned.	2 years ago
Alisdair McDiarmid	fc75657113	terraform: Support sensitive input variable values The stacks runtime interacts directly with the modules runtime's planning operations, rather than through the usual CLI paths. As a result, root module input variable values can be marked as sensitive upon entry. This commit adds support for such marked values to the modules runtime and the `plans.Plan` type. This is sufficient for stacks, which does not use the planfile serialization, but we may in future choose to serialize these decoded marks also.	2 years ago
Liam Cervante	4ce385a19b	testing framework: implement overrides in terraform graph (#34169 ) * testing framework: implement overrides in terraform graph * fix bug for modules and module instances * add test for ModuleInstance.ContainingModule()	2 years ago
hashicorp-copywrite[bot]	53c34ff49c	Update copyright file headers to BUSL-1.1	3 years ago
Liam Cervante	3732bffe13	[Testing Framework] Adds TestContext for evaluating test assertions (#33326 ) * Add test structure to views package for rendering test output * Add test file HCL configuration and parser functionality * Adds a TestContext structure for evaluating assertions against the state and plan	3 years ago
hashicorp-copywrite[bot]	325d18262e	[COMPLIANCE] Add Copyright and License Headers	3 years ago
Liam Cervante	aae6990d38	Add native `plantimestamp` function to Terraform (#32980 ) * add plantimestamp function * documentation * add missing links * fix typo	3 years ago
Martin Atkins	6d9ddbacec	core: Mark errored plans as errored In any situation where we return a plan object along with some errors we'll also explicitly annotate the plan object as being errored so that we can catch if someone accidentally tries to apply that incomplete plan. At the moment this situation is impossible to reach but in a later commit we'll make it possible to save errored plans to disk for further inspection, at which point it'll become important to not allow applying them.	3 years ago
James Bardin	a44c859c86	update UIMode comment	4 years ago
Martin Atkins	3785619f93	core: Use the new checks package for condition tracking The "checks" package is an expansion what we previously called plans.Conditions to accommodate a new requirement that we be able to track which checks we're expecting to run even if we don't actually get around to running them, which will be helpful when we start using checks as part of our module testing story because test reporting tools appreciate there being a relatively consistent set of test cases from one run to the next. So far this should be essentially a no-op change from an external functionality standpoint, aside from some minor adjustments to how we report some of the error and warning cases from condition evaluation in light of the fact that the "checks" package can now track errors as a different outcome than a failure of a valid check. As is often the case with anything which changes what we track in the EvalContext and persist between plan and apply, Terraform Core is pretty brittle and so this had knock-on effects elsewhere too. Again, the goal is for these changes to not create any material externally-visible difference, and just to accommodate the new assumption that there will always be a "checks" object available for tracking during a graph walk.	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	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	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	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
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
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

38 Commits (add-missing-variable-loading)