forked from fediversity/meta
		
	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