47 lines
2.5 KiB
Markdown
47 lines
2.5 KiB
Markdown
# 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](https://git.fediversity.eu/Fediversity/Fediversity/issues/170):
|
|
|
|
```nix
|
|
resources = { config = { ... }; }
|
|
// optionalAttrs (f resources.config) { vm = g resources; }
|
|
```
|