Notes after viewing architecture discussion.

This commit is contained in:
Koen de Jonge 2024-12-04 08:59:57 +01:00
parent 3bdc08106d
commit 8d68fc65ed

View file

@ -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.