feat: Draft resolution for multi-node funding

2026-07-14 13:42:22 +02:00
parent 88e1cde12c
commit d0a3dac9eb
1 changed files with 59 additions and 0 deletions
@@ -0,0 +1,59 @@
+---
+title: "Resolution 043: Budget 018: Multi-Node Coop Cloud"
+---
+
+- Topic: Budget 018: Multi-Node Coop Cloud
+- Date: 2026-07-16
+- Deadline: 2026-07-30
+- Size: Large
+- Budget: 2000€, with possibility of extension in future resolutions
+- Who will implement this: @amras and other willing contributors
+- Duration: Until the budget is exhausted or all goals are met. Estimated end of October 2026.
+
+## Motivation
+Coop Cloud's recipes and tooling were developed to support vertical, single-VPS infrastructure. This was sufficient for a time, because the early member coops used single-VPS infrastructure. However, several newer members have a need for swarms distributed across multiple machines.
+
+In an ideal world we would like to see a plug-and-play model, where user-members of a Coop Cloud instance can contribute multiple (low-power, unreliable) devices to construct a robust network- without relying on a data center.
+
+## Goals
+
+### The Desired Configuration
+- Has one manager node, containing the load balancer
+- Has two worker nodes, which do not rely on local persistent storage
+- Has two data storage nodes
+- Runs abra and at least two recipes
+- Can survive the death of one or both worker nodes, and one data storage node - with only a momentary loss of data/access
+- Provides routing ingress from any node in the swarm
+
+### Example issues to be addressed
+- distributed storage, in particular:
+    * object storage
+    * databases
+    * filesystem/volumes
+ - abra limitations, e.g.:
+	* log retrieval
+	* fetching container status
+	* running commands on remote containers
+- conventions for `deployment:` tags
+
+### Limitations that won't be addressed
+- There are usecases where an operator would want to distinguish between sensitive data stored in one location, and open data accessible to all storage nodes. For this project, we should assume no data is sensitive.
+- While worker nodes and data storage nodes can be treated as unreliable, we will assume there will be only one manager node and a central load balancer. In practice, this would mean that a VPS is still required for a coop cloud deployment - though it could be arbitrarily small and store no user data.
+
+## Project structure and Accountability
+- The hub for this initiative is a toolshed Project
+	- Day-to-day discussions can be held within issue comments
+	- Hours are logged under specific issues
+- An open meeting would be held once a month at a set date, until the conclusion of this project. Any federation members are welcome to join and ask about the status of the project.
+- At the conclusion of the project, or after major milestones, a demo will be presented, e.g. during a Kite Flying hour.
+
+## Budget
+- 2000€, with the possibility to negotiate an extension in the future.
+- Standard rate of 20€/hour
+
+### Work consists of
+- Meetings and Demos
+- Investigating and integrating upstream tools (garage, docker volume plugins, rsync, etc.)
+- Writing documentation and guides for docs.coopcloud.tech
+- Modifying existing recipes
+- Creating and investigating test deployments