87 Commits (5848d8a2b4e0c500c384bcbdcc84b5feec3f6549)

Author	SHA1	Message	Date
Martin Atkins	f1ceee5e69	rpcapi: Stacks.ApplyStackChanges initial implementation ... This wires up the stackruntime.ApplyPlan function to the RPC API with a similar strategy as we used for Stacks.PlanStackChanges wrapping stackruntime.Plan. This is not well tested at all and so probably doesn't quite work right. I'm currently optimizing for getting a reasonable stub of everything into place so that we can have multiple people work together on getting the details sorted afterwards.	2 years ago
Martin Atkins	2a0d407eb6	stackruntime: ApplyPlan function ... This is the exported entry-point for applying a plan that was created by an earlier call to stackruntime.Plan.	2 years ago
Martin Atkins	8719f13b58	stackeval: Stubby implementation of applying changes to components ... This implementation is likely naive and will probably need some refinements in future commits; the goal here is just to stub out the general shape of this so that we can potentially have multiple contributors work concurrently on the subsequent improvements.	2 years ago
Martin Atkins	f8d2fef129	stackeval: Factor out the two "walk drivers" ... With validate, plan, and apply now all at least stubbed out we can see that they all share some similar logic for visiting everything that's relevant to an evaluation phase and gathering up diagnostics and other external reports about each object. Since it's important that the phases all visit the same objects so that we can produce consistent results between phases, we'll accept a little inversion-of-control complexity here in return for now having only two "walk-driver" implementations: one for visiting the "static" objects and one for visiting the "dynamic" objects. - The validate phase only visits static objects. - The plan phase visits static objects first, and then dynamic objects only if the static walk doesn't produce any errors. - The apply phase only visits the dynamic objects. This also required some retroactive changes to some of my earlier work on the validation phase since we can no longer assume that the validation walk is the only one which visits the "static" objects. Their methods now take EvalPhase arguments similar to those for the dynamic objects, and we differentiate between the results in each phase so that we can potentially add slight differences between the phases in future if needed. As of this commit, though, the validate phase and the static portion of the plan phase should produce identical results.	2 years ago
Martin Atkins	fafa36e73a	stackeval: ApplyPlan function and initial supporting internals ... This is a first pass at actually driving the apply phase through to completion, using the ChangeExec function to schedule the real change operations from the plan and then, just like for planning, a visit to each participating object to ask it to check itself and report the results of any changes it has made. Many of our objects don't have any external side-effects of their own and so just need to check their results are still valid after the apply phase has replaced unknown values with known values. For those we can mostly just share the same logic between plan and apply aside from asking for ApplyPhase instead of PlanPhase. ComponentInstance and OutputValue are the two objects whose treatment differs the most between plan and apply, because both of those need to emit externally-visible "applied change" objects to explain their side-effects to the caller. The apply-walk driver has a lot of behavior in common with the existing plan-walk driver. For this commit we're just accepting that and having two very similar pieces of code that differ only in some leaf details. In a future commit we might try to generalize that so we can share more logic between the two, but only if we can do that without making the code significantly harder to read.	2 years ago
Martin Atkins	985b110afa	stackeval: ChangeExec returns states.State from component instance change ... Previously we were returning just a value representing all of the component's output values, but that's the wrong level of detail. In the plan phase we have the corresponding function of ComponentInstance return a plans.Plan object and then derive the object value representing outputs from it only on request. Having the apply result be a *states.State is the analogous level of detail, and then again we'll construct the cty object representing all of the output values only on request during expression evaluation.	2 years ago
Martin Atkins	959b02daa3	stackeval: ChangeExec allows component changes to return diagnostics ... It's annoying to have to complicate our utility function in this way, but it's the most pragmatic way to ensure that the result value and any relevant diagnostics stay associated with one another so we can ensure that we can always handle them both consistently.	2 years ago
Martin Atkins	0ec4acb4ce	stackeval: ChangeExec for orchestrating apply-time changes ... Unlike the plan phase where we just visit everything in no particular order and just let things be scheduled by the Go runtime wherever they happen to get scheduled, we'd like a little more control over the parts of the apply phase that might affect external infrastructure. In particular, we'd like to see some top-level code that is clearly making sure that all of the component instances from the plan are getting handled, rather than leaving that implicit as part of the overall evaluation process. This new ChangeExec function (and associated supporting types) model an explicit setup phase where we register all of the change actions we intend to take, and then an execution phase where those actions can run concurrently with other stackeval work while mediating through the stackeval.Main type as usual. This does require a small amount of tricky finagling to properly sequence the steps so that we can freeze the set of change tasks before we start executing but still give all of the tasks access to the appropriate stackeval.Main object. As usual with this package, the idea is to keep the weirdo promise-based scheduling stuff segregated from the main code so that for everyday maintenence we can hopefully just focus on the straight-through code that represents the main execution rules and worry less about implementation details such as promises and tasks.	2 years ago
Alisdair McDiarmid	54062a52cb	stacks: More extensive in-progress plan events ... Expand the existing hooks to emit events throughout the planning process, providing enough information for the Terraform Cloud UI to render a live-updating representation of the plan. We also sketch out the equivalent hooks for the apply operation.	2 years ago
Martin Atkins	6a45cdf7b0	stacks/stackruntime: Report if provider schema fetching fails ... We were previously just ignoring the errors on the assumption that some other codepath would propagate them, as is our assumption for all inter-dependencies between objects in stackeval. However, provider types are a bit of an oddity right now in that they are really _only_ accessed by implication, and so we don't directly visit them to get an opportunity to gather any errors. We'll hopefully improve on that later, but for now we'll just emit the error once for each component instance to ensure that it gets emitted _somewhere_. We must also stop before trying to call terraform.NewContext if schema loading failed, because otherwise terraform.NewContext itself will fail trying to interact with a provider whose schema it wasn't given.	2 years ago
Martin Atkins	2095a7d000	stacks/stackruntime: Don't panic if component modules are invalid ... ComponentConfig.RequiredProviderInstances was not considering the possibility that ComponentConfig.ModuleTree will return nil if the component's module tree is too invalid to load anything. As usual in stackeval, we need to react to these situations by returning safely to allow another goroutine to return the diagnostic messages that caused the nil result.	2 years ago
Martin Atkins	afd2282aa6	stacks/stackruntime: fix TestPlanWithSingleResource ... We've now upgraded the go-slug dependency to a newer version that fixed the bug that this FIXME comment was referring to, so we can now write the source address correctly and remove the note.	2 years ago
Martin Atkins	c1e7abafc3	stackruntime: Configure and assign provider instances ... Instead of the temporary hack of hard-coding the built-in "terraform" provider, it's now possible to declare configurations for arbitrary providers and assign them to the provider configuration slots of the root module of each component.	2 years ago
Martin Atkins	3dc3781904	stackruntime: Starting up and configuring provider plugins ... Each declared provider configuration is now started up and configured during planning. We don't actually do anything with them yet other than shut them down again once the plan is complete, but we'll improve on that in subsequent commits.	2 years ago
Martin Atkins	373889ae25	stackeval: Actually use the component block "inputs" argument ... Due to some carelessness in earlier refactoring, the components block evaluation was evaluating the "inputs" expression but not actually saving its result, causing all components to get planned with all their input variables set to default values (or failing, if there were any required).	2 years ago
Martin Atkins	7c1dbc9061	stackeval: Don't share objects between AsyncTask closures ... This is, of course, the classic Go for loop hazard where a closure in the loop captures the symbol itself rather than the value of the symbol, and the symbol gets modified directly on each iteration so all of the closures end up referring to whichever value came last. This is just an ugly tactical fix for that intentionally not changing the existing code too much. Hopefully in a future commit we'll rearrange this a little so that it's harder to accidentally reintroduce this bug later, and we should also add some more complex test cases with multiple embedded stack calls and multiple component calls.	2 years ago
Martin Atkins	d1eaf199c9	stackeval: Don't panic if we don't know the input type for a component ... If one of the modules under a component is invalid then we won't be able to determine the expected object type for specifying the input variable values, in which case we should just answer "I don't know" rather than crashing when we're asked to evaluate the input variables object.	2 years ago
Martin Atkins	fbc34005ba	stackeval: Emit PlannedChange for each component instance ... We need to explicitly announce each component instance that we find declared in the stack configuration before we announce any resource instances that belong to it, because callers will rely on this message to create a link between the component instance address on each resource instance and the unexpanded component addresses previously announced by the "find stack components" static analysis call.	2 years ago
Martin Atkins	2d2baee72d	staticcheck: Broadly ignore unused stuff in all of "stacks" ... We're currently actively developing stuff under the "internal/stacks" directory such that there are some loose ends not yet completed in order to make our PRs at least _slightly_ more digestible. For that reason we'll broadly turn off the "unused symbol" checks from staticcheck under that entire directory for now, instead of making many single-file exceptions that will be harder to clean up later. Once the work in this directory settles we should remove this exception so that the stacks-related packages are subject to the same rules as everything else. Unfortunately staticcheck can only work with configuration files if there are no explicit checks on the command line, so this also makes the top-level checks be a configuration file rather than just a command line option in our staticcheck.sh script. The effect for the rest of the codebase is the same, but having the top-level rules in a configuration file means that subdirectories (like "internal/stacks") can inherit from it to minimize the divergence from the typical rules.	2 years ago
Martin Atkins	ea3b70abf0	stackeval: Component calls are now referenceable ... This means it's valid to write references like "component.foo" in expressions in a stack configuration, where the result is built from the planned output values of the root module of each component instance. For embedded stacks we intentionally designed the language to require explicit types on all output values so that we'd still be able to do type checking even when we can't calculate the output values yet. Unfortunately we can't do the same trick for components because the main Terraform module language treats output values as dynamically-typed and so an output value we can't evaluate yet could have literally any type. Therefore we concede and just return cty.DynamicVal in most failure cases here; perhaps a future edition of the main Terraform language can improve this by requiring explicitly-typed output values there too.	2 years ago
Martin Atkins	4a179ed969	stackeval: Very very basic component planning ... This is the absolute bare-minimum integration with the main Terraform language runtime to plan changes for a component. It's intentionally not yet very robust and limited only to the built-in Terraform provider because we're just trying to get the bones in place for seeing stack planning working, rather than trying to build something complete enough to ship. This currently only deals with the resource instance changes that get planned and doesn't expose the root module's output values for use elsewhere in the stack configuration. Output value handling will follow in subsequent commits.	2 years ago
Martin Atkins	d435cd5a1b	stackconfig: Bring the source bundle with the config ... When we load stackconfig we don't immediately load any of the modules that component blocks refer to, so we need to bring the source bundle along with the configuration so that a downstream piece of code (the stack language runtime, currently) can load those from the same source bundle.	2 years ago
Martin Atkins	d3e93e4a31	stackruntime: Initial stubbing of Plan ... This is just enough implementation of "Plan" for embedded stacks with their own input variables and output values, and exposing the final top-level output values as "planned changes". This still doesn't really do anything end-user-useful but it's helpful to have the expression evaluation and plan walk driver machinery in place before moving on to the main useful language element: component blocks. Support for components will follow in subsequent commits.	2 years ago
Martin Atkins	e76e203c77	stackeval: walkState with custom diagnostics handling ... In an earlier commit we added walkState as something we could concisely pass between all of the functions participating in a config/state walk such as what we do in main_validating.go for validation, dealing with the two cross-cutting concerns of firstly detecting when all of the asynchronous operations have completed and secondly aggregating together diagnostics produced by the various objects into a single set. The diagnostics part of this problem was previously solved by just always appending diagnostics into a hidden syncDiagnostics object. That works okay for validation where we just wait until all the work is complete and return all of the diagnostics together as a normal return value, but for planning we expect to be able to stream out both planned changes and diagnostics gradually as the (potentially-slow) planning process proceeds, so the UI can give gradual feedback and thus feel more responsive than just showing an indeterminite progress indicator for the entire operation. To preserve the idea of just passing a single object through the walk functions while giving a little more flexibility, here we introduce an extra hooking capability where the plan phase can treat diagnostics differently while still preserving the same external walkState API. In future commits the plan walk driver functions will all share the same walkState object and the entry point will populate it with the custom callbacks required to create a bridge to the channel-based API for emitting streaming diagnostics. The old simple API is still available for the validate walk to use. Instead of having the internal syncDiagnostics object directly inside the walkState object, it now lives in the local scope created by calling newWalkState, captured into the closures of the two callback functions. The effect is equivalent.	2 years ago
Martin Atkins	355bae32da	stackruntime: Allow hooking the start and end of the overall plan operation ... This broad pair of hooks allows the caller (i.e. rpcapi) to generate a parent tracing span around the entire plan operation, which all other traced operations will descend from. This is also in part just a way to show that the hook API is workable in practice, since these are the first actual hooks.	2 years ago
Martin Atkins	863a91359a	stackruntime: Plan calls into stackeval ... This nudges the placeholder "this is not a real plan" warning down one more level in the stack, with stackruntime.Plan now being equipped to propagate the individual planned changes and diagnostics up to the rpcapi caller, which will in turn propagate them to its client.	2 years ago
Martin Atkins	0111408ca8	stackruntime: Stub of "Plan" function ... This establishes the overall API shape but implementation-wise just moves the warning that the implementation is fake one level deeper, with stackruntime now being the one to return that warning instead of the rpcapi package directly. Package rpcapi now monitors the two output channels from stackruntime.Plan and translates what it sees into protobuf events to transmit to the client. Of course given the above that's currently always just exactly one diagnostic and no planned changes, but we'll start to make the stackruntime.Plan function real in subsequent commits.	2 years ago
Martin Atkins	8af46fd38b	stackruntime: An extensible "hooks" API ... Following a similar model that we've previously used in other parts of Terraform to expose UI-oriented progress events, here we define stackruntime.Hooks as a collection of optional callbacks a caller can use to subscribe to events, and the supporting utility code to help us concisely and correctly call those hook functions from the main evaluation code without adding too much extra noise to the code. Although the primary focus of this API is driving realtime UI updates, the API design also aims to accommodate distributed tracing use-cases by allowing callers to propagate arbitrary values between related event notifications and to inject additional values into the context.Context used for downstream operations that might not be under the direct supervision of stackruntime/stackeval.	2 years ago
Martin Atkins	2b7fad5bee	stackruntime: Our fake telemetry span must be passed by pointer ... Most of our Span actions don't mutate the object because we just immediately emit messages to the test log, but SetName directly modifies the span name so we need to pass by pointer so we can honor that rename.	2 years ago
Martin Atkins	03c981d9d0	promising,rpcapi,stackruntime: Quiet some staticcheck errors ... This code is still under development and so we have some stuff that's there to support further work despite not actually being used yet. We should reconsider these changes later on once the work here has settled.	2 years ago
Martin Atkins	791a5fb8a6	stackruntime: Top-level "Validate" function ... This is the public entry point for the overall validation of an entire stack configuration. So far it supports validation only of input variables, embedded stack calls, and output values. We'll grow this to support other language constructs in later commits. This is a relatively large commit due to introducing various supporting infrastructure to help make evaluation possible at all. Subsequent commits will hopefully be more focused due to being able to depend on the foundations introduced here.	2 years ago
Martin Atkins	8c7acd5378	stackruntime: Helper for viewing traces in tests ... Since our stackeval package is instrumented for OpenTelemetry tracing, it's helpful to be able to see the trace events as part of the test log when debugging. tracesToTestLog arranges for any spans to be announced into the main test log for the remainder of the current test, and then restores the original trace provider afterwards as a test cleanup action.	2 years ago
Martin Atkins	4754889950	stackruntime: Beginnings of Validate function ... This stubs out the basic structure of stackeval's equivalent of a graph walk, which is really just a recursive tree walk starting async tasks that might depend on each other via the abstractions in package "promising". This initial work is sufficient to validate the inputs to an embedded stack call when referring to input variables in the calling stack, showing that the expression evaluation model seems to be working and the use of promises to deal with dependency ordering seems viable.	2 years ago
Martin Atkins	fd4612b804	stackeval: An OpenTelemetry tracer ... This just introduces an OpenTelemetry tracer in a package-level variable but doesn't actually make use of it yet. We'll use it in subsequent commits to help with debugging how different evaluation tasks interact with one another.	2 years ago
Martin Atkins	c5930cc83d	stackeval: Ignore some unused stuff for now ... This package is currently just a stub for design exploration and discussion, so it intentionally has some unused code in it to help suggest how it might evolve in future. We'll remove these staticcheck exceptions later once we're ready to make this code "real", or possibly remove all this code altogether if we decide to take a different direction.	2 years ago
Martin Atkins	59a044dd6f	stackeval: The naming of promises ... If a stack configuration has a dependency cycle we'll tend to detect it by the promises failing to resolve due to a self-reference. Describing that situation to end-users has been historically hard in existing Terraform's dag-based implementation, and there are some similar challenges for this promise-based design too. To deal with it while minimizing runtime overhead in the happy path we'll teach the various objects to retroactively report names for the promises they've already instantiated and then only when we encounter the ErrSelfDependent error will we walk the tree of objects to find user-friendly names for all of the promises that have contributed to the results so far.	2 years ago
Martin Atkins	3d503f8e71	stackruntime: Stubbing the "interpreter" for stack configurations	2 years ago