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
	
	 Kiara Grouwstra
						Kiara Grouwstra