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
	
	 Koen de Jonge
						Koen de Jonge