Details
-
Type:
Epic
-
Status: Rejected
-
Priority:
(None)
-
Resolution: Won't Do
-
Affects Version/s: None
-
Fix Version/s: None
-
Labels:
-
Epic Name:Spontaneous reboot recovery
-
Epic Total Estimate:0
-
DoD:Empty show more show less
Description
Acceptance criteria:
- Implement Update Module API which will ask the Update Module whether it supports resuming from any state
- For modules that do, restart execution at last unfinished state
- Modules that don't must still fail the update, as before (feature is opt-in)
- TBD: What to do about State transition counter (StateDataStoreCount).
- Without it we will not be able to break out of reboot loops and the client will be stuck forever.
- OTOH it does not fit well with long running updates that are constantly postponed. In this scenario we may have dozens, maybe hundreds of reboots before the update is finally applied.
If this is ever considered, we will need to look into how to make this work together with Update Control Maps. Those maps expire, and this needs to be tracked across spontaneous reboots in order for this expiration to ever happen (expiration timeouts can be very long, we can't restart them every time the device reboots or they might never finish).
Attachments
Release management
Issue Links
- relates to
-
MEN-5559 Pause/resume the download of artifacts
-
- Open
-
-
MEN-2293 Support download resume across restarts
-
- Open
-
-
MEN-3360 Make state transition counter disregard state transitions caused by external input
-
- Done
-
-
MEN-3199 Support restarting the deployment from an interrupted Download state
-
- Rejected
-
-
MEN-4196 DBus Update flow control API (i2) for the Mender client
-
- Done
-