127 Commits (8564e934aa57cc59459581ee06479879ebf41bf0)

Author	SHA1	Message	Date
Liam Cervante	b3abff5750	stacks: check providers blocks in components during validatation (#34707)	2 years ago
Liam Cervante	bced645a4d	stacks: call terraform.Validate on stack component configs (#34705)	2 years ago
Liam Cervante	2472f7c773	stacks: fix flaky tests (#34708)	2 years ago
Alisdair McDiarmid	48148eda5f	Merge pull request #34687 from hashicorp/alisdair/stackeval-hook-replace-action-counts ... stackeval: Add support for replace actions to hook	2 years ago
Liam Cervante	64b311d53a	stacks: apply sensitive marks to outputs from components (#34684) ... * stacks: apply sensitive marks to outputs from components * gen headers * ensure consistent test ordering	2 years ago
Liam Cervante	f0b61090a2	Move the testing MockProvider into a dedicated shared package (#34681) ... * move the testing MockProvider into a dedicated shared package * address comments * fix new changes	2 years ago
Alisdair McDiarmid	06723d3d4b	stackeval: Add support for replace actions to hook ... The terraform.Hook implementation in stackeval is used to track the operations performed during stack runtime operations, for later reporting to the caller. This hook did not correctly support the replace actions (create-then-destroy, destroy-then-create), resulting in a loss of data between plan and apply. This exhibited as a plan with a replace reporting 1 add and 1 remove operation, which when applied would report only 1 add operation. Previously, we stored the action performed for each apply operation on a given resource instance in the PreApply hook, then allowed access to it via the ResourceInstanceObjectAppliedAction method. Here we extend the PostApply hook to look for a previous action performed on this instance, and use that to reconstruct the planned replace action. This method is called in the stackruntime package, where replace operations are counted for both add and remove. No changes are needed at the call site to fix the bug.	2 years ago
Martin Atkins	fde6277565	stackruntime: Pass ExperimentsAllowed into stackeval for apply ... This was originally part of 7dad938fdb but unfortunately seems to have got lost during some rebasing, or some other similar sort of annoying reason. This now allows the "experiments allowed" flag to propagate into the stackeval package when we're running the apply phase, for consistency with all of the other phases. Without this, it's possible to plan a configuration that's participating in experiments, but then it fails in a strange way during the apply step due to Terraform suddenly thinking it's a stable release where experiments are disabled.	2 years ago
Liam Cervante	07f6621091	stacks: include resources in state when calculating required providers (#34645) ... * stacks: include resources in state when calculating required providers * also support apply time * add copywrite headers	2 years ago
Martin Atkins	e6665c4f43	stackeval: Basic support for deferred-change propagation ... This is the bare minimum functionality to ensure that we defer all actions in any component that depends on a component that already had deferred actions. We will also eventually need to propagate out a signal to the caller for whether the stack plan as a whole is complete or incomplete, but we'll save that for later commits, since the stack orchestration in Terraform Cloud will do the right thing regardless, aside from the cosmetic concern that it won't yet know to show a message to the user saying that there are deferred changes.	2 years ago
Martin Atkins	67d8a5137b	rpcapi+stacks: Stacks runtime can see whether experiments are allowed ... We allow experiments only in alpha builds, and so we propagate the flag for whether that's allowed in from "package main". We previously had that plumbed in only as far as the rpcapi startup. This plumbs the flag all the way into package stackeval so that we can in turn propagate it to Terraform's module config loader, which is ultimately the one responsible for ensuring that language experiments can be enabled only when the flag is set. Therefore it will now be possible to opt in to language experiments in modules that are used in stack components.	2 years ago
Liam Cervante	3475d22741	Fix nil pointer exception when planning stacks with undeclared variables (#34638) ... * fix nil pointer exception when planning with undeclared variables * another function does the same	2 years ago
Alisdair McDiarmid	55675b990a	stackeval: Unmark provider config for plugin RPC ... When validating or applying a provider configuration, we must unmark the value before attempting to use plugin RPC, as we cannot serialize marks.	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
Martin Atkins	0994e6fbf9	stacks: The terraform.workspace attr is not available in Stacks ... The terraform.workspace attribute is a rare example of a CLI- and Cloud- specific concern bleeding into the Terraform language, and it can only really have meaning when used in the traditional Terraform workflow because otherwise there's no workspace to return the name of. In Stacks any variations between instances of a module must be created through input variables. Within Terraform Cloud in particular it's also possible to use stack-level input variables that are assigned different values from different stack deployments, and thus an author can recreate the effect of terraform.workspace using a stack-level input variable that has a different value for each deployment. This is one of the few cases where the Terraform module language differs in stacks compared to traditional Terraform. Any module that makes use of terraform.workspace will need to be generalized to use input variables instead before it can be used within a stack component. Prior to this change, references to terraform.workspace from a module used in a stack component would just panic altogether, because the stacks runtime doesn't provide the object that the workspace name would be taken from. Now we'll return a user-oriented error instead.	2 years ago
Martin Atkins	7d2d4dec5e	stackeval: When being destroyed, component instance result comes from plan ... Because we treat dependency edges as reversed when a component instance is being destroyed, the final result (an object representing output values) for a component instance being destroyed must not depend on anything else in the evaluation graph, or else we'd cause a promise self-reference as the downstream component tries to configure itself based on our outputs. As a special case then, for a component instance being destroyed we take the planned output values directly from the plan, relying on the fact that the plan phase sets them to the prior state output values in that case, and therefore the result for such a component is available immediately without blocking on any other expression evaluation during the apply phase. This combines with several previous commits to create a first pass at handling ordering correctly when planning and applying a full destroy. This commit also incorporates some fixes and improvements to stackeval's apply-time testing helpers, which had some quirks and bugs when first added in a recent commit. One of those problems also revealed that the raw state loader was not resilient to a buggy caller setting a state entry to nil instead of removing it altogether, and that mistake seems relatively easy to make (as I did here in the test helper) so we'll tolerate it to make it possible to recover if such a bug does end up occurring in real code too.	2 years ago
Martin Atkins	dcb176a557	stackeval: A Main for applying knows the plan it's applying	2 years ago
Martin Atkins	c06ad051a1	stackeval: Respect inter-component dependencies during apply ... Before we start any apply-time actions for a particular component, we'll block until other components' apply are complete. In the normal case a component instance waits until its dependencies have been applied. However, if component instances are being destroyed then they instead wait for their _dependents_ to complete being applied, since a component must outlive all other components that depend on it.	2 years ago
Martin Atkins	c345cde93c	stackeval: Extended utilities for plan and apply testing ... These helpers make it easier to write our tests because the plan and apply phases both work in a callback-based fashion where they gradually emit events, and that's not a very convenient API for test code to interact with. This exposes some more details about the planning results, and also adds a new similar helper for the apply phase. We'll make use of both of these in future commits.	2 years ago
Liam Cervante	9246b3a994	stacks: on module load convert relative paths to absolute (#34523)	2 years ago
Liam Cervante	7d143388f3	Add support for the cross resource type move operation in the proto schema (#34480) ... * Update proto schema and provider interfaces with support for moved across resource type RPCs * address comments * remove unused functions * remove support for flatmap format	2 years ago
Martin Atkins	3c14eeb945	stackeval: Make some provisioners available to stack components ... This makes the built-in "remote-exec" and "file" provisioners available for use in the modules that implement stack components. These are both relatively easy and low-risk to include because they are builtins and don't require anything from outside of Terraform itself. For now this intentionally excludes local-exec because we'll want to think about what constraints we want to put on it, if any, to help ensure we can meet the goal of stack configurations being portable between different execution environments without significant modification, and our current stacks execution environment doesn't guarantee the availability of any external software _at all_. The motivation for adding this now is just to give some better feedback when someone uses a module using one of these provisioners, since otherwise they'll see just a confusing generic error message from the modules runtime about the provisioners not being available. I expect we'll revisit this later and consider expanding it to at least include local-exec, and _maybe_ external provisioner plugins, although that's more questionable because the provisioner plugin mechanism is incredibly legacy and doesn't have any way to work outside of local Terraform CLI usage today. There are no tests here yet because these provisioners are not mockable and would depend on having an SSH or WinRM server to connect to. Later we should ponder how to make this more testable, which might mean making another part of the system responsible for actually providing the provisioner factories and thus our tests here can use fakes. The goal here is just to get this done in a relatively lightweight way for better feedback during preview though, so we're not yet ready to make significant time investments here.	2 years ago
Alisdair McDiarmid	1d3f863f2b	stackruntime: Support sensitive component inputs ... Components can emit sensitive values as outputs, which can be consumed as inputs to other components. This commit ensures that such values are correctly processed in order to pass their sensitivity to the modules runtime.	2 years ago
Alisdair McDiarmid	e4b319401e	stacksruntime: Add sensitive outputs tests	2 years ago
Martin Atkins	3961c18420	stackeval: Return an error if a module contains a provider config ... When using stacks the provider configurations belong in the stack configuration rather than inline in the individual modules. Shared modules with inline provider configurations has been a deprecated legacy practice for many years now, but traditional Terraform continued to support it for backward-compatibility with older modules despite the significant downsides of doing so. Stacks now finally removes that capability, since it isn't straightforward to continue supporting it once we've made the stacks runtime be responsible for instantiating and configuring providers.	2 years ago
Martin Atkins	a51c034cc3	stackeval: Include component configurations in our static walks ... This means both that the validate walk can now describe static problems in the component's module tree, and that we'll catch such problems earlier in the planning phase and thus avoid reporting them repeatedly in cases where a component block uses for_each to declare multiple instances. This includes a fix to a bug in StackConfig.Components, which was incorrectly using the input variable declarations as the source for its result, instead of the component declarations.	2 years ago
Martin Atkins	a3cd4a11ce	stackeval: Use relative, slashy paths in module-related diagnostics ... Until we've updated the module config loader to be sourcebundle-aware and thus return proper source addresses, this will at least make the paths we show in diagnostics a little less verbose, and more consistent across platforms.	2 years ago
Martin Atkins	a4d61733f6	stackplan: Include extra info in raw component instance plan ... We'll now track the planned action, the component addresses we depend on, and the planned output values.	2 years ago
Martin Atkins	25a514f846	stackeval: Populate planned component instance more thoroughly ... We'll now track a more realistic Action, the components that the component instance depends on, and the planned output values.	2 years ago
Martin Atkins	524da4f278	stackeval: Applyable objects have a set of required components ... To figure out the required order in which we'll apply the plans for all components we need to know how data flows between them. We'll use what's added here during the plan phase to record in the plan which components depend on which other components, and then the apply phase will use that coarse information to schedule the individual component apply operations into a suitable order. None of that is implemented here though, and will follow in future commits. This commit includes new documentation about the apply scheduling approach which includes some mechanisms that are not actually yet included in this commit, but will follow shortly after. This is just a pragmatic compromise to avoid spending time authoring short-lived partial documentation drafts for the intermediate steps while still keeping these increments small enough for practical review.	2 years ago
Martin Atkins	00761a9f70	stackeval: ApplyChecker is now Applyable ... We chose this name originally to communicate that implementations are only responsible for checking that an apply was successful, but in future commits this interface will also gain the additional responsibility of helping to gather the information required to understand the dependency relationships between components that will then drive the scheduling of the apply actions during the apply phase.	2 years ago
Martin Atkins	11bb10ba72	stackeval: Find references in arbitrary expressions and bodies ... Along with full expression/body evaluation, we'll also need to be able to determine what an expression or body refers to without evaluating it, so that we can use references to infer dependency relationships between significant side-effects in the apply phase, such as the relative ordering of applying the changes for different components.	2 years ago
Martin Atkins	306b9008c4	stackeval: Clean some debug junk in ComponentInstance ... I apparently missed this when I was preparing my previous round of commits in this area. Mea culpa.	2 years ago
James Bardin	2574b899e7	Merge pull request #34385 from hashicorp/jbardin/provider-functions-impl ... client-side implementation of provider functions	2 years ago
Matej Risek	039cced8ae	Add component address to ComponentInstance under AppliedChanges (#34418)	2 years ago
James Bardin	2923ba6ac3	add CallFunction to stub provider	2 years ago
Martin Atkins	be33a7e9e0	stackeval: Use prior state outputs when planning component destroy ... When a component is planned for full destroy, we should assume that its apply phase will be delayed until everything that depends on it has been destroyed, since otherwise we'd be violating the dependency relationship. That means that the expression value for a component pending destruction ought to be based on the output values from the prior state (which ought to have been refreshed as part of planning destroy) rather than the desired state (in which case all of the output values would be unset). This commit only deals with the _planning_ part of this problem, and only deals with the situation where we're planning a "full destroy" of the entire stack configuration and therefore all component instances in the configuration are going to be destroyed. In future commits we'll need at least the following additional work to complete this: - The apply phase needs to learn to schedule component instance destroy actions differently than other component instance actions, so that destroy cannot begin until everything that depends on the component has already been destroyed. - We also need to deal with the situation where only a particular component instance has been removed from the configuration, in which case only that one component instance is planned for destroy and everything else is planned as normal. In that case it would be invalid for anything to still be referring to that component instance in the configuration, and so the work in this commit would actually be irrelevant, but it'll take some other separate machinery to make sure that the removed component instances still get planned properly, which they don't today. This commit is just an incremental step toward the final correct behavior, which should allow the planning of a full destroy to succeed, although actually applying that plan is still likely to fail because the apply phase will not respect the required order of operations yet.	2 years ago
Martin Atkins	a47dc447c1	stackeval: Additional testing utilities ... In earlier commits we stubbed out some testing utilities as part of adding some unit tests, but we didn't end up using all of them in the initial round and it turned out that some of them were incorrect or incomplete. Now we'll improve the test utilities, this time with a focus mainly on integration-type tests, because we'll start adding those in the near future. Specifically: - utilities for rendering diagnostics, mainly in situations where they are unexpected and thus we just want to see the full information as part of the test results - helper functions for concisely asserting that there should be no diagnostics at all, or that there should be no error diagnostics - the existing helper for faking up a prior state based on hard-coded raw state messages was incorrect in that it was trying to use statekeys.Key values as map keys, and those values are not typically comparable. Instead, we should use the string representations that are designed to be used as unique map keys. - the testPlan function, and the lower-level testPlanOutput it's built with, help to encapsulate the asynchronous event-emitting behavior of Main.PlanAll into a "normal-looking" function that just blocks until it's done and then returns all of its results. This automatically round-trips the planned changes through serialization and deserialization as we would between a normal plan and apply phase, and so the calling test can make its assertions against the applyable plan object instead of the raw component parts it's made from.	2 years ago
Martin Atkins	2aba28eb1a	stacks: Track component instance existence in the state ... Although we can often use the presence of resource instances in a component instance as an implication of the component instance's existence, it's possible (albeit rare) for a component instance to have no resources in it at all, and thus it would be ambiguous whether it exists or not. Now we'll track the existence of the component instances themselves as extra objects in both the raw state and the state description. Along with their existence we'll also track a snapshot of the output values as they were at the most recent apply, which for now is primarily for external consumption but we'll also include them in the raw state in case it ends up being useful for something down the road.	2 years ago
Martin Atkins	b0b8d4aa6f	states: Only track root module output values ... For a very long time we've had an annoying discrepancy between the in-memory state model and our state snapshot format where the in-memory format stores output values for all modules whereas the snapshot format only tracks the root module output values because those are all we actually need to preserve between runs. That design wart was a result of us using the state both as an internal and an external artifact, due to having nowhere else to store the transient values of non-root module output values while Terraform Core does its work. We now have namedvals.State to internally track all of the throwaway results from named values that don't need to persist between runs, so now we'll use that for our internal work instead and reserve the states.State model only for the data that we will preserve between runs in state snapshots. The namedvals internal model isn't really designed to support enumerating all of the output values for a particular module call, but our expression evaluator currently depends on being able to do that and so we have a temporary inefficient implementation of that which just scans the entire table of values as a stopgap just to avoid this commit growing even larger than it already is. In a future commit we'll rework the evaluator to support the PartialEval mode and at the same time move the responsiblity for enumerating all of the output values into the evaluator itself, since it should be able to determine what it's expecting by analyzing the configuration rather than just by trusting that earlier evaluation has completed correctly. Because our legacy state string serialization previously included output values for all modules, some of our context tests were accidentally depending on the implementation detail of how those got stored internally. Those tests are updated here to test only the data that is a real part of Terraform Core's result, by ensuring that the relevant data appears somewhere either in a root output value or in a resource attribute.	2 years ago
Martin Atkins	b64953dba3	stacks: Summary docs giving an overview and some details about stackeval	2 years ago
Martin Atkins	3f569b55c5	stacks: Some code consistency cleanups in preparation for first merge	2 years ago
Martin Atkins	8a99c3c0e5	stacks+rpcapi: Add some missing copyright comments	2 years ago
Martin Atkins	3678815bb3	stackeval: Tests for provider instance configuration evaluation	2 years ago
Martin Atkins	1872c9d9be	stackeval: inPromisingTask cancels context when test completes ... This is just some extra insurance to reduce the risk of us leaving things dangling after a test terminates. Although tests should ideally not rely on this and should terminate background work properly as part of the test, this should catch some things that might get left behind if a test ends in an ungraceful way.	2 years ago
Martin Atkins	94ca9bc613	stackeval: testEvaluator arranges for its result to be cleaned up ... Some operations against an "evaluator" (type Main) register cleanup actions that need to be run once the evaluation has completed. To avoid leaking resources while we're running tests we'll arrange for any test that uses the "testEvaluator" helper to automatically run the cleanup actions on the returned evaluator once the test is complete. At the time of this commit the only possible cleanup action is terminating any provider pluginc client processes that might be running, and none of our tests are actually doing that so this doesn't really change anything, but it's here to avoid problems if we add additional cleanup actions in future, or if any tests start actually using child plugin processes.	2 years ago
Martin Atkins	d7461ce202	stackeval: Initial tests for type "Provider" ... These tests focus on the behaviors related to deciding the set of dynamic instances for a particular provider and producing the values that act as references to providers. These tests also revealed a small but important bug in ExprReferenceValue in the for_each case, which is now fixed as part of this commit.	2 years ago
Martin Atkins	d3e0b89e02	stackeval: Some initial tests for the Component type ... This includes Component.CheckInstances and Component.CheckResultValue.	2 years ago
Martin Atkins	91b8ea3d76	stackstate: A helper for loading state during tests ... The main entry point here assumes the caller is providing serialized state objects wrapped in anypb.Any messages. That's an inconvenient representation for hand-writing in tests, so the new function LoadFromDirectProto allows skipping the deserialization steps and instead has the caller write the wanted values as if they had already been parsed/unmarshaled.	2 years ago
Martin Atkins	95ff474ee9	stackeval: Tests for StackCall.ResultValue	2 years ago