This documentation talks about two strategies that seem really similar to me:
kill-then-download
When an update is available, the Supervisor kills the container for the old version.
After this, the Supervisor downloads the image for the new version.
Once the download is complete, the Supervisor creates and starts the new container, and deletes the old image from disk.
delete-then-download
When an update is available, the Supervisor kills the container for the old version, and then deletes the corresponding image.
After this, the Supervisor downloads the image for the new version.
Once the download is complete, the Supervisor creates and starts the new container.
Comparing the two strategies, why wouldn’t I always want to use delete-then-download? It will reduce the amount of storage used/required by the device?
I think the main difference is that recovering from a bad container update with kill-then-download is easier because the previous container still exists. With delete-then-download, the supervisor can’t recover to the previous version since the supervisor deleted the container after killing it. It has to download the previous version from Balena. The trade-off as you said is that kill-then-download takes up more space during an update.
I might be totally wrong on the automatic reversion part. I can’t find anything in the docs about that, probably best for someone more knowledgeable than me to chime in. Sorry for the confusion