Update modules - report inconsistent

Description

By using update modules (MEN-2000), the device may be left in an inconsistent state if there are any failures during the installation.
We need to flag these devices with failure somehow so that users are aware (both on device, e.g. standalone, and UI/API side).
Users should be allowed to deploy further updates, but they should know about the failure before the next deployment.

User value

  • Reduce risk of bricking devices by making further deployments on inconsistent devices

  • Reduce support cost by avoiding scenarios where future deployments succeeds on some devices but fails on others for reasons hard to diagnose (in distant past)

Size (SP)

  • TBD

Acceptance criteria

  • Device must report that it is in inconsistent state if an artifact with no rollback has failed, or if an artifact with rollback has failed, and then also failed its rollback

  • Devices in the inconsistent state must be able to reinstall the same update again (avoiding the usual "already installed" deployment state)

    • So probably the inconsistent state can not be an inventory attribute, since it must be used in deployment decisions

  • State must be visible in the GUI

  • It must be possible to query the state on the device (CLI option or plain file)

Risk & mitigation

TBD

Market Goal

Increase market share by supporting application updates

Checklist

Activity

Show:

eystein.maloy.stenberg June 18, 2020 at 4:51 PM

Ah yes, this was reorganized, thanks for pointing it out.

Let's close it!

Kristian Amlie June 18, 2020 at 6:44 AM

: I just realized that all acceptance criteria in this tickets have been fulfilled by the Update Modules feature since last year already. Shall we just close it or do we want a better "inconsistent" state than the name based one we have now?

eystein.maloy.stenberg January 10, 2019 at 6:55 PM

Thanks !
Indeed, history is a bit larger, should think of this in context of as well. When we get there we can change this Epic or take the other one with some extra acceptance criteria.

In order to not plan too for ahead, let's wait with planning this (creating new Epics) until we are closer to development.

Kristian Amlie January 10, 2019 at 8:23 AM

As agreed in the planning I will implement a simple name-based "inconsistent" state for now.

We also agreed that we would choose the history approach to partial updates: Keep a list of previously installed partial updates, so that the contents of devices can be compared. I think a separate epic for that makes sense, doesn't it?

Kristian Amlie December 11, 2018 at 8:10 AM

Yes, agree. Sounds less ominous!

Unresolved

Details

Assignee

Reporter

Labels

Epic Name

Goals

None

Priority

Backlog

Zendesk Support

Checklist

Created November 2, 2018 at 8:41 PM
Updated June 25, 2024 at 12:02 PM