80 lines
2.6 KiB
Plaintext
80 lines
2.6 KiB
Plaintext
|
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.
|
||
|
|
|