From 8d68fc65ed23a584b77ec01e467edb24a181459f Mon Sep 17 00:00:00 2001
From: Koen de Jonge <koen@fediversity.eu>
Date: Wed, 4 Dec 2024 08:59:57 +0100
Subject: [PATCH] Notes after viewing architecture discussion.

---
 ...wing_architecture_discussion_from_Koen.txt | 79 +++++++++++++++++++
 1 file changed, 79 insertions(+)
 create mode 100644 architecture-docs/2024-12-04Notes_after_reviewing_architecture_discussion_from_Koen.txt

diff --git a/architecture-docs/2024-12-04Notes_after_reviewing_architecture_discussion_from_Koen.txt b/architecture-docs/2024-12-04Notes_after_reviewing_architecture_discussion_from_Koen.txt
new file mode 100644
index 0000000..3a50090
--- /dev/null
+++ b/architecture-docs/2024-12-04Notes_after_reviewing_architecture_discussion_from_Koen.txt
@@ -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.
+