Status command
SijmenHuizenga opened this issue · 2 comments
We are working on an embedded device where the user will have to manually trigger the download & install of an update when one is available. We will be calling rauc-hawkbit-updater --run-once whenever the user requests to install an update. We want to show the details of the upcoming update to the user before downloading.
We need a way to know what rauc-hawkbit-updater would do if it were invoked. I propose we add the --status command that prints in a single-line status message and exits with a status code. For example:
| exit code | message |
|---|---|
| 0 | Everything up-to-date. No updates available. |
| 1 | Update available: <name> (<version>) |
More statuses could be added.
The --status flag would only work when running together with --run-once.
What do you think? Let's talk! I am happy to implement this if we agree on the interface.
FYI: --run-once does not work for this at the moment, neither the download nor the install thread can finish in this case (as of c65e3c5). I have patches in my queue that are waiting for #68, #71, and a (to be created) "hawkbit client refactoring" PR to get merged before. These patches make rauc-hawkbit-updater wait for the download and install threads properly. I needed them to allow download/install test cases (also waiting in queue).
As far as I can see hawkBit is not expecting such a scenario you desribe, you targets will be marked overdue as they do not poll regularly. Also you won't be able to gather information about your targets (see config data) - at least not until the user triggers rauc-hawkbit-updater.
I'm wondering if user approval for download and/or installation couldn't be integrated in a fashion closer to what hawkBit expects, with rauc-hawkbit-updater constantly running. This again would probably require a rauc-hawkbit-updater DBus interface.
Maybe let's take a step back: what are the advantages of using rauc-hawkbit-updater for your case compared to poll/download/install a bundle by your application from a regular HTTP server?
Thanks a lot @Bastian-Krause for the details explanation ❤️. I now see the problem with using --run-once, so we won't be using that. The plan changed to downloading the files directly and calling rauc through the d-bus api. Thanks 😄