87 Commits (5848d8a2b4e0c500c384bcbdcc84b5feec3f6549)

Author	SHA1	Message	Date
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
Martin Atkins	333c502990	stackeval: Support each.key, each.value, count.index and self references ... For all contexts where these have a defined value, they can now be used in expressions and evaluate to whatever they ought to evaluate to.	2 years ago
Martin Atkins	75602fa9eb	stackeval: Tests for StackCall.Instances	2 years ago
Martin Atkins	48d2d15a40	stackeval: Some basic tests for OutputValue.CheckResultValue	2 years ago
Martin Atkins	13edd30479	stackeval: Test-only globals ... Because many stacks language features are dependent on others to do useful work, it's tempting to focus only on integration testing of combinations of features used together. However, we known from our experience with the modules runtime (the "terraform" package) that over time this becomes a huge maintenance burden, because any non-trivial change tends to invalidate hundreds or thousands of integration tests, and because of their broad scope its often hard in retrospect to figure out what exactly a particular test was aiming to test vs. what it was just relying on as a side-effect. To try to minimize these cross-dependencies and thus enable something closer to unit testing, here we introduce a special kind of symbol to the stacks language which is available only to unit tests in this package. "Test-only globals" -- an intentionally-clunky name to avoid squatting on useful names -- can be set as part of the Main object and, when defined, are available for use in all situations where we perform expression evaluation against a stack. The "globals" in the name represents that, unlike just about everything else, they are defined once but available in all stacks in the configuration tree. This design is a tradeoff: it introduces a bunch of extra code that is here entirely to support testing, but hopefully this code is segregated enough from everything else that it's unlikely to change significantly under future maintenance, thereby hopefully minimizing the need for future cross-cutting test maintenance too.	2 years ago
Martin Atkins	bb0e833785	stackeval: Remove stale comment about output value changes ... This comment was originally assuming we'd need a separate field to track the type information for the serialized output values, but we actually don't need that because the type information is encoded in-band in the MessagePack representation of the values.	2 years ago
Martin Atkins	0281170645	stackeval: Remove stale todo about prior state in plans ... This TODO was noting that an earlier version of this code was not including any prior state information in the "modules runtime" plan. At the time I wrote the comment I was expecting to handle that here as a separate step, but I later refactored this to include the prior state as part of the returned plan, since that's where the modules runtime expects to find it during the apply phase anyway. This comment is therefore now redundant, because no extra work is required in this location to get the prior state populated.	2 years ago
Martin Atkins	992f6d4115	stackeval: Fix input variable evaluation in embedded stacks ... Two bugs were making this not work quite right: - The Stack type wasn't treating its child stack objects as singletons, instead creating a new one on each request and therefore preventing child objects from being treated as singletons too. - StackCallInstance.CheckInputVariableValues wasn't actually using the value from its expression evaluation, and was instead just always returning an empty object. This commit also includes the tests that helped find these bugs.	2 years ago
Martin Atkins	9a943af56d	stackruntime: Arbitrary expression evaluation ... Here we introduce a new evaluation phase for the stacks runtime called "inspect", which aims to provide a read-only view of a configuration and an associated state snapshot. The main idea of this is to use it as a more convenient vehicle for unit testing despite it not really being viable to decompose the main evaluation logic into smaller parts: the language features are all directly interdependent on one another, but we can at least minimize our interactions with the Terraform modules runtime when we're testing anything other than actually planning and applying components. However, this also gives an opportunity to expose evaluation of arbitrary expressions in a similar manner as "terraform console", which is for now just another debugging aid but will probably someday appear as a Stacks-flavored version of the "terraform console" command.	2 years ago
Martin Atkins	d689237a48	stackeval: Tests for the "perEvalPhase" helper	2 years ago
Martin Atkins	5aaed3111e	stackeval: Reusable and testable for_each handling ... Previously we had some similar code duplicated into each of the three kinds of object that support for_each: components, embedded stack calls, and provider configurations. Instead, we'll hoist that code out into a function that all three can call. We can then actually test that function in isolation (independently of the three callers) to get more confidence that future maintenance won't inadvertently break the slightly-unusual contract of treating a nil map differently from a non-nil empty one, which is unfortunately likely to defy the expectations of a typical Go developer since those two values are normally considered equivalent.	2 years ago
Martin Atkins	1180096850	stackeval: Unit tests for EvalExpr and EvalBody	2 years ago
Martin Atkins	3c6c5effd5	stackeval: Applying must use apply-time provider clients ... Previously we were incorrectly trying to use the plan-phase provider clients during the apply phase, which causes the provider to get configured as it would during the plan phase and, in particular, crashes if the provider configuration refers to input variables because the plan-phase input variables are not available during the apply phase.	2 years ago
Martin Atkins	6e7eff9b4b	stackruntime: Report deletion of resource instance objects ... Previously our strategy for reporting the "applied change" results for resource instance objects was to iterate over the final state and emit an object for each resource instance we found in there. That's not a sufficient solution though, because if any objects are deleted as part of applying the plan then they won't be in the final state and so we won't know to tell the caller that they should drop the relevant objects from the stack-level state. Instead, we'll keep track of all of the resource instance objects that could potentially be affected by applying a plan and then use that set to decide which "applied change" objects to emit. If one of the affected objects is not present in the final state then we'll assume it was deleted and so command the caller to delete its records of that object from both the raw state and the state description. With this in place, it's now possible to create a destroy-mode plan and then apply it to end up with no resource instances at all. The stack runtime itself is still missing handling of destroying its own objects like components and embedded stacks, so this isn't a complete solution but it does at least allow properly cleaning up the records of objects that exist in remote systems, so it's now easier to clean up a development environment with real infrastructure backing it.	2 years ago
Martin Atkins	c6894cc617	stackeval: ComponentInstance: all output values during planning ... If planning fails partway through then we might have an incomplete set of planned changes for our root output values. Previously any output values we hadn't visited yet would get omitted altogether from the value representing a component instance, which is likely to cause confusing downstream errors if any other expression is referring to those missing output values. Instead, we'll use the configuration to find all of the statically-configured output values and fill out any that don't have a planned change with a placeholder cty.DynamicVal. This will make references to those output values return an unknown value, instead of raising an error.	2 years ago
Martin Atkins	972f1c0678	stackplan: Track provider config for every resource instance change ... Previously we were still partially relying on the record of this in the embedded planproto object, but since we're now allowing "planned changes" that don't actually include a change in that traditional sense we need to track the provider configuration address separately as a top-level field. As with some of the addresses before, this means we're now storing the provider config address redundantly in two places when there _is_ a planproto change. Hopefully we'll improve that someday, but we don't need to sweat it too much right now because this only affects the internal raw plan format that is not subject to any compatibility promises between releases, so we can freely change it in any future version.	2 years ago
Martin Atkins	4e34e6ebfa	stacks: Track prior state for all resource instance objects ... Previously our raw plan data structure only included information about resource instances that have planned actions, which meant we were missing those which only get their state updated during refresh and don't actually need any real work done. Now we'll track everything, accepting that some "planned changes" for resource instance objects will not actually include a planned change in the typical sense, and instead only represent a state update.	2 years ago
Martin Atkins	61ccc09681	stacks+rpcapi: Wire through the "plan mode" to the stacks runtime ... Previously we were accepting it at the API layer but then silently discarding it and always creating a "normal" plan. Now we'll pass the caller's selected planning mode all the way through to the modules runtime in component plans. This isn't actually quite sufficient to properly support destroy-mode plans since the stacks runtime itself doesn't yet really understand how to deal with things being destroyed, but this is intended to be just enough for those working on callers of this API to see _some_ effect from setting the planning mode, even though it's far from the full effect expected. More work on destroying will follow in subsequent commits.	2 years ago
Martin Atkins	af0c4764ef	stackeval: A FIXME about emitting prior state snapshots during apply ... Currently we're not explicitly writing the results from the refresh phase to the raw state or state description, which means that a refresh-only plan wouldn't do anything and even in a normal plan there are some edge-cases where we'll end up not saving the refreshed state. This is just a note to remind us of that in later work.	2 years ago
Martin Atkins	8fd29e9439	stacks: Preserve prior state from plan to apply ... We need to retain the prior state (in a form that Terraform Core's modules runtime can accept) between the plan and apply phases because Terraform uses it to verify that the provider's "final plan" is consistent with the initial plan. We previously tried to do this by reusing the "old" value from the planned change, but that's not really possible in practice because of the historical implementation detail that Terraform wants state information in a JSON format and plan information in MessagePack. This also contains the beginnings of handling the "discarding" of unrecognized keys from the state data structures, although we'll probably need to do more in that area later since this is just the bare minimum.	2 years ago
Martin Atkins	5372d5eb98	stacks+rpcapi(stacks): Model deposed objects for resource instances ... Previously we incorrectly assumed that resource instances only have one "current" object each. However, resource instances can also have deposed objects which we must also keep track of. This is a breaking change to the rpcapi since we're now using a new message type for a resource instance _object_ address in several places. That breakage is intentional here because at the time of writing this commit the rpcapi is not yet in any stable release and we want to force updating our existing internal client to properly handle deposed objects too.	2 years ago
Martin Atkins	2559151d0a	stackruntime: Count actions successfully applied ... Callers expect to be given an updated set of counts for how many of each action were completed, which we'll achieve by having the terraform.Hook implementation keep track of those and then announce them based on what it collected. We can't use the plan for this directly because terraform.Context.Plan seems to modify the plan it's given during its work, and on success the plan ends up being totally empty.	2 years ago
Martin Atkins	5d9cac85bc	stackruntime: Emit "pending" events for component instance plan/apply ... Previously we did have an event for planning but it wasn't in quite the right place, and so could potentially appear "late" and mess up the event sequence. Now we'll always emit the pending event immediately before the planning or applying event, which is perhaps a little redundant but having these separated means that we might be able to create some space between them later if we find that we need to do some additional work after we know about a component instance but before we're reading to say that we're planning or applying it.	2 years ago
Martin Atkins	947c483c49	rpcapi: Stack plan and apply use the same progress message type ... Previously we had the progress messages directly inlined as events of the PlanStackChanges operation, but that means that there's no common interface type for progress events across both the plan and apply phases, making it hard for Go implementations to share marshaling code between the two phases. Now we'll use a new StackChangeProgress message type to contain all of the progress message situations. This makes constructing and using the progress messages a little more verbose -- an extra layer of message -- but means that we can write code that works generically with the StackChangeProgress generated struct and thus share it between the two phases, leading to less code overall. As of this commit we don't yet have the apply phase generating any progress messages, but we'll extend it in a subsequent commit now that it's possible to share more of that event-generating code between the two phases.	2 years ago
Martin Atkins	1943ed2395	stackruntime: Emit some more progress hooks during the apply phase ... This is not quite comprehensive yet, but echoes the main component start/end events we emit during the planning phase, and some of the resource-instance-related events. The rpcapi layer is not yet consuming all of these events and so most of this will just be no-op right now; we'll add the rpcapi translation layer for these in subsequent commits.	2 years ago
Martin Atkins	c4d7ee93fb	stackeval: Use the right EvalPhase in various places ... In an earlier commit I generalized some code that was originally written for the plan phase to be shared between the plan and apply phases, but missed a few spots where it was still hard-coded for the plan phase. Hopefully this is all of them!	2 years ago
Martin Atkins	69aa51b9ff	stackruntime: Fix some quirks of data sent from plan to apply ... We previously took a few shortcuts just to more quickly produce a proof of concept. This gets us considerably closer to a properly-working handoff from plan to apply, at least for create, update, and replace actions. Destroying stuff that's been removed from the configuration will take some further work since currently everything we do is driven by objects in the configuration. That will follow in later commits.	2 years ago
Martin Atkins	569f0f553b	stackruntime: ComponentInstance considers previous state ... Now that we have access to a previous state snapshot during the planning phase, we can pass the relevant parts to the modules runtime when asking it to plan changes for a component instance. This is not yet complete enough for full support of consecutive plan and apply runs that preserve state, but it gets the needed data plumbed in and we'll continue making this more complete in subsequent commits.	2 years ago
Martin Atkins	aaba750095	rpcapi: Stacks: pass previous state to stack runtime during planning ... As of this commit it doesn't yet do anything with it, but we'll plumb that in more deeply in subsequent commits.	2 years ago
Martin Atkins	49511fe9a8	stackstate: Fuller round-tripping of resource instance object state ... This gets us ever closer to being able to preserve resource instance objects from one run to the next. In subsequent commits we'll make use of the "LoadFromProto" option to load the prior state during the planning phase and take it into account when we're deciding what actions to propose.	2 years ago
Martin Atkins	13e26b60dd	addrs: Adopt DeposedKey as an address type; remove states.Generation ... Previously we had states.DeposedKey as our representation of the unique keys used to differentiate between multiple deposed objects on the same resource instance. That type is useful in various places, but its presence in the "states" package made it troublesome to import for some callers. Since its purpose is as an identifier, this type is more at home in the "addrs" package. The states package retains a small number of aliases to preserve compatibility with a few existing callers for now, until we have the stomach for a more invasive change. This also removes the largely-redundant states.Generation interface type, which initially was intended as a way to distinguish between "current" objects and deposed objects, but didn't really add anything because we already have addrs.NotDeposed to represent that situation. Instead, we just ended up with various bits of boilerplate adapter code converting between the two representations. Everything now uses addrs.DeposedKey and uses addrs.NotDeposed to identify non-deposed objects.	2 years ago
Martin Atkins	d1b0632e82	stackruntime: Add HashiCorp copyright comments	2 years ago
Martin Atkins	74215a4451	stacks: Include resource type schema in PlannedChange and AppliedChange ... Unfortunately for historical reasons the "terraform" package produces state and plan artifacts that have dynamic data elements pre-encoded in the formats that Terraform CLI's traditional plan and state formats use. Since Stacks uses different plan and state models, and exclusively uses MessagePack encoding for dynamic values in both, we'll sometimes need to transcode from one format to another when generating and decoding the stacks-oriented representations. Transcoding between these serialization formats requires access to the relevant schema because the formats themselves each have an infoset that is only a subset of Terraform's type system. Therefore we'll now annotate the PlannedChange and AppliedChange objects that include provider-specific data types with the schema required to transcode them. This commit does not yet actually arrange to make use of those schemas. That will follow in later commits.	2 years ago
Martin Atkins	48518b8233	stacks: A very basic stub of applied resource instance change announcements ... We'd like to start developing some clients for this part of the RPC API concurrently with remaining work here in Terraform Core, and so this is a bare-minimum implementation of emitting "applied change" events for resource instances just so there's something for client developers to test against. There are various things wrong with this, including but not limited to: - It always reports that the new state for a resource instance is an empty object, rather than including the correct updated object. - It only supports "current" resource instance objects, and ignores deposed ones. - It just uses the resource instance address alone as the key for the state description map, which is fine for now when we only have one kind of description object anyway but will not be sufficient for a real implementation that needs to emit various different kinds of object. We'll need to rework most of this in future commits, but this is hopefully sufficient to start implementing and testing API clients, at least to some extend, despite the crudity of the results.	2 years ago
Martin Atkins	d99985720f	stacks: Carry input variable values from plan to apply ... We need to preserve the input variable values provided during the plan phase so we can reuse them during the apply phase to recalculate derived results based on new information learned during the apply process. We also need to recalculate the input values for individual components during the apply phase, so we can react to previously-unknown values that come from other upstream components.	2 years ago
Martin Atkins	b887d29894	stackeval: NewForApplying must save the ChangeExecResults object ... This was just an oversight in some earlier refactoring. An ApplyPhase instance of Main must store a pointer to the ChangeExecResults object that will capture all of the results of the main side-effects of applying the plan, since we'll need to retrieve those results to evaluate expressions and other similar downstream results based on those outcomes.	2 years ago
Martin Atkins	de170a9a30	stackeval: InputVariable should respect EvalPhase when deciding value ... Previously it was still hard-coding PlanPhase, which was a cheat we did in earlier work when we were just exploring the overall design of this package. It will now pass ApplyPhase when running in the apply phase, although Main.RootVariableValue doesn't yet have any implementation for retrieving variable values frozen during planning so root input variables will always be unknown values during the apply phase for now. We'll fix that in a future commit.	2 years ago
Martin Atkins	373f39d6ac	stackeval: ApplyPlan's ChangeExec must be in main task ... The ChangeExec call creates new promises, one of which the caller is responsible for resolving by calling the "begin" callback. To correctly follow the rules of the "promising" package we must resolve that promise in the same task that created it or explicitly delegate it to another task. In this case it's fine to just resolve it, but for that to work correctly we need to call "begin" from the same task as ChangeExec was called from.	2 years ago
Martin Atkins	b8923a5f94	stackruntime: Persist a component's plantimestamp in the plan ... We need to preserve the module runtime's chosen plan timestamp through to the apply phase so that plantimestamp function calls during the apply phase will return the same result as during the planning phase. This also means that we will now no longer emit a "component instance" planned change object if the planning operation fails so much that there is no plans.Plan object returned, but that's at least consistent with the fact that we also don't report any resource instance changes in the same situation. Event emission is always best-effort when the result has errors.	2 years ago
Martin Atkins	8f00a7bf5a	stackruntime: Make sure PlanResponse and ApplyResponse channels get closed ... The closure of these channels is how a caller knows that the operation has completed, so we must always close them before we return or the caller is likely to get wedged.	2 years ago
Alisdair McDiarmid	927350eca8	rpcapi: Add component expansion and change summary ... We want to report the result of component expansion to the client as early as possible, so that it can prepare to receive any following information for each instance. This message is critical when a component's expansion expression evaluates to an empty set: without this message's confirmation of this case, it will be unable to determine that the component will receive no plans for any instances until the plan completes. We also want to report a roll-up of the resource changes upon completion of each component's plan and apply operations, so that a client can summarize the operation changes without performing the roll-up operation on all received change events.	2 years ago