forked from Fediversity/meta
49 lines
1.6 KiB
Markdown
49 lines
1.6 KiB
Markdown
**Changes in the workforce!**
|
||
|
||
- Taeer is leaving modus / fediversity
|
||
- Nicolas is joining in his stead
|
||
- Hans is also coming back
|
||
- Jimena is leaving the project as well.
|
||
|
||
|
||
**Architecture document**
|
||
|
||
- "Different design choices" A.K.A. shortcuts
|
||
|
||
1.
|
||
|
||
- Before the idea was that all you needed was a pile of hardware, and our application would take care of everything on top of that with NixOS
|
||
- Now: use a layer in between for virtualisation, clustering, etc. that's already been invented
|
||
|
||
- Kubernetes: too complicated
|
||
- proxmox: not as complicated
|
||
|
||
2.
|
||
|
||
- Before: share services between organizations
|
||
- Now: each organization has its own set of services
|
||
|
||
|
||
|
||
Question: How do you handle inter-service communication?
|
||
Example: Matrix, authentication mechanism. Do they run together or are they separate services?
|
||
DNS (TBD), Email (stalwart), Authentication (TBD), Backend storage (garage).
|
||
|
||
|
||
|
||
Bogdan: unclear about the implications of using Proxmox
|
||
|
||
Original question regarding kubernetes/nixops was: can we design around features that kubernetes has
|
||
|
||
Is the feature of kubernetes of dynamic scaling quickly is actually something that is currently needed in fediversity architecture
|
||
proxmos allows scaling in virtual machines, (missed a part here), and is already familiar for lots of people
|
||
|
||
it also gives api to deploy that nixops can communicate with
|
||
|
||
Koen will adjust the architecture document next week to include the Proxmos, and then meet with Taeer and Nicolas on Wednesday Sept 4th at 4pm NL time
|
||
|
||
|
||
|
||
**Communication**
|
||
Koen wants daily updates posted publicly, but this is still open for discussion
|
||
Posting updates to our existing fediverse instances |