forked from fediversity/meta
		
	Notes after viewing architecture discussion.
This commit is contained in:
		
							parent
							
								
									3bdc08106d
								
							
						
					
					
						commit
						8d68fc65ed
					
				
					 1 changed files with 79 additions and 0 deletions
				
			
		| 
						 | 
					@ -0,0 +1,79 @@
 | 
				
			||||||
 | 
					3 Layers:
 | 
				
			||||||
 | 
					* Management
 | 
				
			||||||
 | 
					* Virtualization
 | 
				
			||||||
 | 
					* Hardware
 | 
				
			||||||
 | 
					
 | 
				
			||||||
 | 
					== Management ==
 | 
				
			||||||
 | 
					Parameters like 'domain-name' and 'e-mail name'
 | 
				
			||||||
 | 
					
 | 
				
			||||||
 | 
					- resource provider (what is it exactly, definition? API tussen NixOPS and Central DB)
 | 
				
			||||||
 | 
					
 | 
				
			||||||
 | 
					Central databases:
 | 
				
			||||||
 | 
					* accounting data
 | 
				
			||||||
 | 
					* state of the system
 | 
				
			||||||
 | 
					* netbox - 'network layout' (maar dat is meer)
 | 
				
			||||||
 | 
					
 | 
				
			||||||
 | 
					Do we need a 'monolith' database that contains all the 'soll' (source of truth) state?
 | 
				
			||||||
 | 
					Central database should be 'high availability' (should never be down)
 | 
				
			||||||
 | 
					
 | 
				
			||||||
 | 
					=> data model
 | 
				
			||||||
 | 
					- is that part of the architecture?
 | 
				
			||||||
 | 
					- how can it evolve (procedures!)?
 | 
				
			||||||
 | 
					
 | 
				
			||||||
 | 
					Golden standard flow:
 | 
				
			||||||
 | 
					- Name and version of service definition is known
 | 
				
			||||||
 | 
					- Operator enters 'choices' (can be hostnames, configuration options, styles etc) in to NixPanel
 | 
				
			||||||
 | 
					- NixPanel makes API request
 | 
				
			||||||
 | 
					- That is then fed to NixOPS
 | 
				
			||||||
 | 
					- NixOPS gathers and evaluates needed resources (IP-addresses, Virtual Machine(s), Storage, DNS-entries, (system)e-mail addresses)
 | 
				
			||||||
 | 
					- NixOPS creates the needed resources and updates the 'state' database and 'accounting' database and feeds that back to other systems
 | 
				
			||||||
 | 
					- NixPanel gets 'system ready' state from the 'state' database and presents that to the Operator
 | 
				
			||||||
 | 
					
 | 
				
			||||||
 | 
					TODO: put in UML
 | 
				
			||||||
 | 
					
 | 
				
			||||||
 | 
					TODO: Case story 'if you want to build' it works like this.
 | 
				
			||||||
 | 
					
 | 
				
			||||||
 | 
					TODO: Glossary of 'terms and definitions'
 | 
				
			||||||
 | 
					
 | 
				
			||||||
 | 
					TODO: 'create' 'use' 'destroy'
 | 
				
			||||||
 | 
					
 | 
				
			||||||
 | 
					REMARK: secrets manamagement != identity management
 | 
				
			||||||
 | 
					
 | 
				
			||||||
 | 
					TODO: user-stories 'Operators' and 'Service Managers' etc.
 | 
				
			||||||
 | 
					
 | 
				
			||||||
 | 
					
 | 
				
			||||||
 | 
					== Services and FediServices ==
 | 
				
			||||||
 | 
					It makes more sense to split those on a technical base:
 | 
				
			||||||
 | 
					It does not really make a lot of sense
 | 
				
			||||||
 | 
					
 | 
				
			||||||
 | 
					== API ==
 | 
				
			||||||
 | 
					NixConfigurator: NixOPS + ssh
 | 
				
			||||||
 | 
					VirtualisationProvider: currently Proxmox but could be replaced/extended.
 | 
				
			||||||
 | 
					Email: Stalwart
 | 
				
			||||||
 | 
					DNS: deSEC? (Ronny is pushing for a non-NixOS dns solution)
 | 
				
			||||||
 | 
					IdentityManagement: ?
 | 
				
			||||||
 | 
					ObjectStorage: Garage
 | 
				
			||||||
 | 
					
 | 
				
			||||||
 | 
					== Bootstrapping ==
 | 
				
			||||||
 | 
					* Creates all the needed infrastructure on hardware
 | 
				
			||||||
 | 
					
 | 
				
			||||||
 | 
					Misconception: NORDUnet does not need any insight in the architecture.
 | 
				
			||||||
 | 
					
 | 
				
			||||||
 | 
					Non-NixOS virtual machines: place them out of scope.
 | 
				
			||||||
 | 
					We DO care about Proxmox not being NixOS right now, we just cannot fix everything at the same time.
 | 
				
			||||||
 | 
					
 | 
				
			||||||
 | 
					
 | 
				
			||||||
 | 
					== Backups ==
 | 
				
			||||||
 | 
					* All configuration that is 'scope of the provider' should be backupped (using ZFS snapshots and database dumps)
 | 
				
			||||||
 | 
					* All 'user data' should be backupped by having 'another provider' that this is replicated to (also safeguards against lock-in)
 | 
				
			||||||
 | 
					BACKUPS
 | 
				
			||||||
 | 
					
 | 
				
			||||||
 | 
					WE DO NOT GIVE 'backup to Amazon as an example'
 | 
				
			||||||
 | 
					
 | 
				
			||||||
 | 
					
 | 
				
			||||||
 | 
					== Hardware layer ==
 | 
				
			||||||
 | 
					Is wel degelijk onderdeel van het project.
 | 
				
			||||||
 | 
					Is niet 'just there' want we hebben dat helemaal ontworpen en in elkaar gezet en daar zijn best wel uren in gegaan.
 | 
				
			||||||
 | 
					Wat daar mist is de documentatie en het 'hoe doe je dat nu eigenlijk' documentatie
 | 
				
			||||||
 | 
					Dit is best een integraal onderdeel van het project.
 | 
				
			||||||
 | 
					
 | 
				
			||||||
		Loading…
	
	Add table
		
		Reference in a new issue