-
Notifications
You must be signed in to change notification settings - Fork 192
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Concept: Simple Update Server Support (and Life Cycle Handling) #1114
Labels
enhancement
Adds new functionality or enhanced handling to RAUC
Milestone
Comments
This was referenced Jun 5, 2023
Note that a notable number of features from the list above already made their way into RAUC. With #1152 we can now actually configure RAUC to expose information like boot id, transaction id on the first HTTP request. See https://rauc.readthedocs.io/en/latest/advanced.html#additional-http-header-information. More advanced features like polling or rollout scheduling are still to be done. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Problem
So far, the options for using RAUC in network-based OTA update scenarios are:
rauc-hawkbit-updater
as a clientTypical features that can be required by an OTA update server are:
Excluding the custom server approach, the other two options are on opposite ends of the spectrum:
Now, since RAUC can directly download/stream bundles from an HTTP server, the idea is to equip RAUC with capabilities that support the above-mentioned features with a simple HTTP server (and optionally with little custom application logic).
Some of the required RAUC-side capabilities are currently missing for all scenarios. The most important one is the lack of update life-cycle state handling that would allow RAUC to more reliably detect and report a successful reboot of a just-updated system.
Possible Solution
The following generic features can be implemented in RAUC to support the usage of simple update servers.
RAUC should optionally send some HTTP headers to the server. In the simplest case, this information can be logged by the server and introspected by the rollout operator. In more complex setups, the server can add some custom application logic and use the headers for filtering etc.
The information reported to the server should be configurable and can be either standard information that is already available in RAUC or additional information retrieved by the
system-info
handler.System state information like a boot id, an update transaction id, and a general update cycle state should be generated and stored to allow RAUC to conclude if the system actually rebooted, if it rebooted to the expected system, etc.
Automated polling for updates at a defined location (URL) can be implemented as part of the RAUC service.
Simple rollout 'scheduling' can be realized by configuring an update time range for the devices. Each individual target chooses its point in time (in a reproducible manner) where it actually performs the download and update. This ensures not all platforms update at once to limit server load and allows operators to stop rollouts.
The text was updated successfully, but these errors were encountered: