2.5 KiB
Sync with Robert on NixOps4 dependencies for the MVP
The current idea is to control Terraform from NixOps4 at the resource provider level and handle data flow in NixOps4
While we could interface with Terraform as a whole and let it handle its own dataflow, we'd be programming three components, and the idea was to reduce the number of components we need to take care of
Another option would be integrating terranix, but that's an entire different user story
Arguably we can implement all the variability for an otherwise fixed set of resources (such as secrets, DNS, ...) with what we have already
Nested deployments are only required if we have CLI-first use cases that operate directly on expressions
For demo purposes until further notice, our parameters are a constant as far as NixOps4 is concerned, and its internal data dependencies can be resolved e.g. in the front end's data model
More important for now is having TF provider wrappers for common use cases, because that is where the application value lives
- kiara: i'm not sure i see TF wrapping as as important as nested deployment, fallback way if we need a TF step seems embed/use TF itself
On progress indication: NixOps4 is using the tracing library underneath, which offers separate events and spans (with start and end)
Adding JSON output is a quick fix
The CLI progress indicator already uses this infrastructure
There's no interface for providers yet, because so far the assumption is that they're short-lived
Having that would be nice, but note that it would require substantial changes to NixOS build/activation logging
Most of the value can already be provided by the NixOps4 core, given it knows which resource providers need to be run and which are done
Could be follow OpenTelemetry in a creative way so NixOps4 doesn't have to own the schema
Long term providers could talk via API servers using some IDL such as capnproto
Conclusion: We will drop JSON into the nixops invocation for the MVP and use the basic JSON logging infrastructure for progress indication
Mid term we'll want Terraform provider wrappers to do the resource provisioning
We can continue discussing long-term architecture decisions (such as protocols, concurrency, scheduling) independent of near-term milestones
Expression demonstrating the infinite recursion that would be resolved using nested deployments:
resources = { config = { ... }; }
// optionalAttrs (f resources.config) { vm = g resources; }