terraform

Commit Graph

Author	SHA1	Message	Date
Liam Cervante	e704da535e	stack: stacks should be applyable even if no components are (#35498 )	2 years ago
Daniel Schmidt	4433239da4	stacks: validate dependency lockfile in apply phase	2 years ago
Daniel Schmidt	0e5f7acda0	stacks: validate dependency lockfile in planning phase	2 years ago
Daniel Schmidt	46999364f0	stacks: refactor for plantimestamp to come from the outside	2 years ago
Liam Cervante	284ce63947	stacks: applyable status should be dependent on applyable components (#35350 )	2 years ago
Liam Cervante	1bb78c14c2	deferred actions: always enable deferred actions in stacks (#35321 )	2 years ago
Daniel Schmidt	59ead5356f	stacks: update RPC APIs with deferral information (#35125 ) * stacks: add deferred resource instance planned change to protobuf * stacks: add deferred resource instance to stack plan sequence * stacks: add planned change for deferred actions * stacks: refactor planned change resource instance planned moving the components out of the main function definition so that we can reuse the implementation for deferred resource instances which wraps the message used for PlannedChangeResourceInstancePlanned * stacks: track deferred changes in stackplan * add simple tests * fix tests * address comments --------- Co-authored-by: Liam Cervante <liam.cervante@hashicorp.com>	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	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	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	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	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	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

17 Commits (stacks-variable-validations)