Update Strategy: When to use kill-then-download vs delete-then-download?


#1

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?


#2

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.


#3

Ah, I didn’t know the supervisor did automatic reversion on failure.


#4

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


#5

All good, thanks for the response. Looking forward to hearing from someone who knows more about this issue as well. :slight_smile: