YunoHost-esque fearless upgrade scripts? #682

New Issue

decentral1se · 2025-12-19T10:33:32Z

decentral1se commented

2025-12-19 10:33:32 +00:00

@notplants can you set the stage for this one?

From our discussion I understand the wish for:

a "blessed" configuration per-recipe which becomes stable and maintainers focus on. e.g. "gitea + sqlite is the recommended configuration and we test this one" vs. "try these 19 $chaos.compose.yml" combinations and good luck to everyone.
instead of only release notes, we can include a script in the recipe configuration which will perform the actual actions required to get from version x to y successfully. YunoHost does this extremely well and we can probably learn from this.

If there is anything we can do to bake in commands to make upgrades more stable, I'm all for it!

This + the recipe maintainers proposal finally getting implementation could really improve all our lives.

@notplants can you set the stage for this one? From our discussion I understand the wish for: 1. a "blessed" configuration per-recipe which becomes stable and maintainers focus on. e.g. "gitea + sqlite is the recommended configuration and we test this one" vs. "try these 19 $chaos.compose.yml" combinations and good luck to everyone. 2. instead of only release notes, we can include a script in the recipe configuration which will perform the actual actions required to get from version x to y successfully. YunoHost does this extremely well and we can probably learn from this. If there is anything we can do to bake in commands to make upgrades more stable, I'm all for it! This + the recipe maintainers proposal finally getting implementation could really improve all our lives.

fauno commented

2025-12-19 13:54:35 +00:00

related to #578

notplants commented

2025-12-20 03:11:28 +00:00

I think this comment summarizes the essence — I also made a longer doc here titled “What Can Co-op Cloud Learn From Yunohost”: https://doc.commoninternet.net/RorkLLTWTWabFyr-rqO2bA?both#

I don’t personally know abra well enough yet to really have much to say about implementation details — but I can say that years of doing upgrades on apps with yunohost was significantly less stressful than doing upgrades on co-op cloud apps, and I’m curious if there are ways to even that out without totally going against the coop cloud model.

In particular, feels to me like a “blessed automated upgrade path” has a lot of potential for getting benefit from the “configuration commons” ideal in way that operators all independtly figuring out updates does not.

Automating updates also sort of goes hand-in-hand with seamless rollbacks too (of data +code), because when the magic goes wrong good to know it’s easy to revert.

Seems like code rollbacks are pretty straightforward right now with abra, and with data it’s sort of there with backupbot, but maybe not all quite seamlessly integrated yet into something along the lines of the pseudocode:

backup —> preupgradebackup
try:
   update 
   test_all_services_working 
except:
   restore —>preupgradebackup

In my dream world, if the auto update doesn’t work — it safely rolls back — and then, when you have time to debug, you go back to doing things the current way (a bunch of deploy —chaos), and ideally merge your fixes back into the upgrade script of the recipe so others don’t run into the same issue.

I think this comment summarizes the essence — I also made a longer doc here titled “What Can Co-op Cloud Learn From Yunohost”: https://doc.commoninternet.net/RorkLLTWTWabFyr-rqO2bA?both# I don’t personally know abra well enough yet to really have much to say about implementation details — but I can say that years of doing upgrades on apps with yunohost was significantly less stressful than doing upgrades on co-op cloud apps, and I’m curious if there are ways to even that out without totally going against the coop cloud model. In particular, feels to me like a “blessed automated upgrade path” has a lot of potential for getting benefit from the “configuration commons” ideal in way that operators all independtly figuring out updates does not. Automating updates also sort of goes hand-in-hand with seamless rollbacks too (of data +code), because when the magic goes wrong good to know it’s easy to revert. Seems like code rollbacks are pretty straightforward right now with abra, and with data it’s sort of there with backupbot, but maybe not all quite seamlessly integrated yet into something along the lines of the pseudocode: ``` backup —> preupgradebackup try: update test_all_services_working except: restore —>preupgradebackup ``` In my dream world, if the auto update doesn’t work — it safely rolls back — and then, when you have time to debug, you go back to doing things the current way (a bunch of deploy —chaos), and ideally merge your fixes back into the upgrade script of the recipe so others don’t run into the same issue.

Sign in to join this conversation.

3 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: toolshed/organising#682