I have the following (seemingly simple) update strategy in mind for my project:
Download the latest version of the app whenever it’s available
Keep running the older version of the app to avoid downtime / interruption
Next time the device is rebooted or power-cycled (that’s up to the end user), the updated app should be run instead of the old one. The old app / image can now be deleted.
Is it possible to get this behavior using one of the built-in update strategies ? I think the answer is no (unless I implement an unnecessarily complex hand-over strategy)
Is download-then-kill (default strategy) plus update-locking a better way to go about it ? If so, could you please point me in the right direction ? Thanks
Hey, any reason the reboot is required step of the strategy you are thinking about? In general, we see that people want the device to restart as few times as possible, and it seems like it would contradict your downtime/interruption requirement.
If I understand correctly, you mainly just want the update to happen at a give time, allowed by the manager of the device. Is that so? If yes, I think update locking should be all that you need: the device will download the updates, but will only apply and start the new version when you trigger the update lock override from the dashboard (in the device actions section), the sdk, or supervisor (using the force option). The key is the update locking, not any change in update strategy.
Probably the quickest way is to just test this setup out on a simple project, and see how it works in practice. Would probably combine it with delta updates, to minimise the amount of data downloaded.
any reason the reboot is required step of the strategy you are thinking about?
My project is an untethered autonomous robot, not an IoT device. Even if its single-board computer is never rebooted or shutdown programmatically, at some point the end user will have to change the battery. The end user will also power it down at the end of the day. So the idea is to take advantage of the necessary reboot / power-cycling to switch to the latest version of the app.
I created the /data/resin-updates.lock but then I couldn’t reboot or shutdown the device via the Supervisor API. It was responding with the following error:
# curl -X POST --header "Content-Type:application/json" "$RESIN_SUPERVISOR_ADDRESS/v1/reboot?apikey=$RESIN_SUPERVISOR_API_KEY"
Updates are locked: EEXIST: file already exists, open '/mnt/root/resin-data/######/resin-updates.lock'
Maybe the solution is to lift the lock, reboot/shutdown, update, then place the lock again?
Looking at the docs, seems like the CLI has some info, that the reboot command and the shutdown command are also blocked by the update lock,.
Could you try running the command with adding --data '{"force": true}'?
curl -X POST --header "Content-Type:application/json" --data '{"force": true}' "$RESIN_SUPERVISOR_ADDRESS/v1/reboot?apikey=$RESIN_SUPERVISOR_API_KEY"
My guess is that the docs got out of sync and have to add there that the update lock blocks these actions too.
As for the update on reboot, that sounds a tricky criteria. With containerised apps, their uptime and system uptime is separated. It looks to me that uptime shows the system uptime in the application container, so could possibly implement an update trigger in your application that depends on the system uptime.
Just something to note, that the supervisor takes some time to start up, and at startup there’s a ~30 window at the moment when your application might be already running, but the supervisor not running yet (some more info in this conversation).
Ah, that explains it! Thanks for looking into it Gergely
As for the update on reboot, that sounds a tricky criteria. With containerised apps, their uptime and system uptime is separated. It looks to me that uptime shows the system uptime in the application container, so could possibly implement an update trigger in your application that depends on the system uptime.
Good point. Thanks for the heads-up!
I’ll experiment with a few approaches (on a simple project, like you suggested) and report back if something sticks.
