5 commits

Author	SHA1	Message	Date
Martin Atkins	6981b9f8c6	planning: Dependencies between resource instance object subgraphs ... The previous commit arranged for each resource instance object with a planned change to have an execution subgraph generated for it, but didn't honor the dependencies between those objects. There's now a followup loop that adds all of the needed "waiter" edges after the fact, including both the "forward" dependencies between create/update changes and the "reverse" dependencies between delete changes. The shape of the leaf code here got quite messy. In future commits I intend to work on cleaning up the details more, but the main focus here was to restore the execgraph building functionality just enough to prove that this new two-pass planning approach gives us enough information to insert all of the needed dependency edges. Signed-off-by: Martin Atkins <mart@degeneration.co.uk>	2026-02-23 10:25:42 -08:00
Martin Atkins	f801baa7a2	planning: Add execution graph ops for resource instance objects ... This is the first chunk of the work to construct an execution graph based on the intermediate representation in resourceInstanceObjects. For now this just constructs an independent subgraph for each resource instance object, without honoring any of the inter-object dependencies. A subsequent commit will add in all of those dependencies in an additional loop afterwards. Signed-off-by: Martin Atkins <mart@degeneration.co.uk>	2026-02-23 10:25:42 -08:00
Martin Atkins	1e0a920a34	planning: Sketch of even more managed resource instance actions ... This provides at least a partial implementation of every resource instance action except the ones involving "forget" actions. However, we don't really quite have all of the building blocks needed to properly model "delete" yet, because properly handling those actions means we need to generate "backwards" dependency edges to preserve the guarantee that destroying happens in reverse order to creating. Therefore the main outcome of this commit is to add a bunch of FIXME and TODO comments explaining where the known gaps are, with the intention of then filling those gaps in later commits once we devise a suitable strategy to handle them. Signed-off-by: Martin Atkins <mart@degeneration.co.uk>	2026-02-10 07:07:01 -08:00
Martin Atkins	ac9a26d5b9	exec: ManagedDepose and ManagedChangeAddr take object as operand ... These both effectively had the behavior of ResourceInstancePrior embedded in them, reading something from the state and change its address as a single compound operation. In the case of ManagedDepose we need to split these up for the CreateThenDestroy variant of "replace", because we want to make sure the final plans are valid before we depose anything and we need the prior state to produce the final plan. (Actually using that will follow in a subsequent commit.) This isn't actually necessary for ManageChangeAddr, but splitting it keeps these two operations consistent in how they interact with the rest of the operations. Due to how the existing states.SyncState works we're not actually making good use of the data flow of these objects right now, but in a future world where we're no longer using the old state models hopefully the state API will switch to an approach that's more aligned with how the execgraph operations are modeled. Signed-off-by: Martin Atkins <mart@degeneration.co.uk>	2026-02-10 07:07:01 -08:00
Martin Atkins	db8c872def	planning: Initial unit tests for managed resource instance execgraph ... We're currently being intentionally cautious about adding too many tests while these new parts of the system are still evolving and changing a lot, but the execGraphBuilder behavior is hopefully self-contained enough for a small set of basic tests to be more helpful than hurtful. We should extend this test, and add other test cases that involve more complicated interactions between different resource instances of different modes, once we feel that these new codepaths have reached a more mature state where we're more focused on localized maintenance than on broad system design exploration. Signed-off-by: Martin Atkins <mart@degeneration.co.uk>	2026-02-09 07:35:50 -08:00