toolshed/docs.coopcloud.tech
3
2
Fork 27
Code Issues 10 Pull Requests 1 Packages Releases Activity

docs: moar rant
All checks were successful
continuous-integration/drone/push Build is passing
Details

Browse Source
This commit is contained in:
decentral1se
2026-03-27 14:38:20 +01:00
parent c521548e77
commit b883e574c7
1 changed files with 1 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
docs/abra/swarm.md
View File

@ -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.