add progress indicator architecture meeting notes
This commit is contained in:
parent
fbc0e5f445
commit
3d0fcb801e
1 changed files with 45 additions and 0 deletions
45
meeting-notes/2025-03-03-progress-indicator-meeting.md
Normal file
45
meeting-notes/2025-03-03-progress-indicator-meeting.md
Normal file
|
@ -0,0 +1,45 @@
|
|||
# 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
|
||||
|
||||
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; }
|
||||
```
|
Loading…
Add table
Reference in a new issue