# 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; }
```