From b883e574c7910cce92f39f9727b99f4fe796a14b Mon Sep 17 00:00:00 2001 From: decentral1se Date: Fri, 27 Mar 2026 14:38:20 +0100 Subject: [PATCH] docs: moar rant --- docs/abra/swarm.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/abra/swarm.md b/docs/abra/swarm.md index 0045533..1bc137b 100644 --- a/docs/abra/swarm.md +++ b/docs/abra/swarm.md @@ -52,4 +52,4 @@ In practice, this is what we currently rely on Swarm mode for. * A way to namespace services into a deployment, aka a "Docker Stack". This would appear to be a minor implementation detail after all is said and done. It's services all the way down and they have some linked networks/configs/volumes/etc. and a shared naming convention. -* Some way to achieve [Fearless YunoHost-esque Upgrades](https://git.coopcloud.tech/toolshed/organising/issues/682#issuecomment-29302). In other words, some predictable way to deploy / upgrade / rollback and some way to intervene when things go wrong. It should be easy to understand for everyone and would enable real stability for operators. I think we want some sort of anti-orchestration implementation which is super simple. +* Some way to achieve [Fearless YunoHost-esque Upgrades](https://git.coopcloud.tech/toolshed/organising/issues/682#issuecomment-29302). In other words, some predictable way to deploy / upgrade / rollback and some way to intervene when things go wrong. This means we have a "one by one" deployment model which would respect `depends_on` and have explicit way to configure roll backs (instead of it happening whenever Swarm feels like it). It should be easy to understand for everyone and would enable real stability for operators. I think we want some sort of anti-orchestration implementation which is super simple.