Pantavisor based devices are quite robust when it comes to device updates.
In Pantavisor terms an update is called a revision. A revision is always an increasing sequence, thus if the current revision is say 10 the next revision would be 11.
Each revision can be identified from it’s revision number but if more descriptive identifier is required then while posting a revision we can use the
--message (-m) parameter of pvr binary to put in commit messages which also appear in the Pantahub page and device can be easily identified.
Whenever a new revision is available pantavisor, by default, will try to download the first such available revision. If more than one such revisions are pending they’ll all be tried in the order they are posted.
Thus for example,if revisions 10,11,12 are availale for a device then device will try to update the device in the same order.
Configuring update retries
It’s possible that a revision can’t be applied at the moment which could be due to network disruption. Pantavisor, by default, retries an available update.
This behaviour is controlled by two configuration entries in pantavisor.config
|Parameter||Description||Default Value||Value Type|
|revision.retries||Number of retries for applying an available revision||10||integer|
|revision.retries.timeout||Duration between two consecutive retries||120 (seconds)||integer|