9 Commits (stacks-variable-validations)

Author	SHA1	Message	Date
Alisdair McDiarmid	d828776757	stacks+rpcapi: Load prior state and plan separately ... Previously we expected clients to provide an inline raw prior state to PlanStackChanges and an inline raw plan to ApplyStackChanges, which was a simpler design but meant that we might end up generating a state or plan that's too large to be submitted in a single gRPC request, which would then be difficult to resolve. Instead we'll offer separate RPC functions for loading raw state and plan using a gRPC streaming approach, which better mirrors the streaming approach we use to _emit_ these artifacts. Although we don't actually need this benefit right now, this makes it possible in principle for a client that's running PlanStackChanges to feed back the raw planned actions concurrently into OpenPlan and thus avoid buffering the whole plan on the client side at all. This required resolving the pre-existing FIXME about the inconsistency where stackeval wants a raw plan for apply but expects the caller to have dealt with loading the prior state for planning. Here it's resolved in the direction of the caller (rpcapi) always being responsible for loading both artifacts, because that means we can continue supporting the old inline approach for a while without that complexity having to infect the lower layers. Ideally we should remove the legacy approach before this API becomes constrained by compatibility promises, but I've preserved the old API for now to give us some flexibility in when we update the existing clients of this API to use the new approach. Co-authored-by: Martin Atkins <mart@degeneration.co.uk>	2 years ago
Daniel Schmidt	4433239da4	stacks: validate dependency lockfile in apply phase	2 years ago
Martin Atkins	c57f709b1d	stackruntime: Pass the apply-time variable values to stackeval ... This seems to have got lost while resolving some conflicts in 88eec94896. Without this, apply-time input variable values just get ignored entirely and if any are required the plan is not applyable at all. Now we'll pass through what the caller provided so stackeval can validate and use it properly.	2 years ago
Martin Atkins	e74896bd24	stackruntime: Handle apply-time-specified input variables ... When the topmost stack configuration declares an ephemeral input variable, its values must be provided separately for each of the plan and apply phases. Therefore here we extend the API to allow specifying input variable values during the apply phase, and add rules to check whether all of the apply-time-required input variables have been specified and whether any non-ephemeral variables are either unspecified or re-specified with equal values during the apply phase. This also extends the FindStackConfigurationComponents response to include more metadata about the input variables and output values so that a caller can know which ones are ephemeral. The name of that RPC function had already become a little too specific with the inclusion of embedded stack information and is even moreso now; we might choose to rename it to something more generic like "AnalyzeStackConfiguration" in future, but that'd be a breaking change and therefore requires more coordination.	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
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
Martin Atkins	d1b0632e82	stackruntime: Add HashiCorp copyright comments	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
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