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.
Revisions are identified from its revision number. If a more descriptive identifier is required then while you can use the --message (-m) parameter of pvr to add a commit messages during the commit. This will also appear in the Pantacor Hub UI and is easily identified on the device.
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 availalbe for a device then the 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 |