hawkbit-client: Add support for soft rollout action type with optional D-Bus readiness check#217
hawkbit-client: Add support for soft rollout action type with optional D-Bus readiness check#217a-elkaim wants to merge 2 commits into
Conversation
109f99c to
b28cdb7
Compare
|
Just skimming through this: I think this has some overlaps with #165, which implements the DBus interface on rauc-hawkbit-updater's side. Due to the size and limited time, we have not had the chance to review that unfortunately. But your approach seems interesting. Maybe @UVV-gh has an opinion on this one? I guess you'll need some patience until this gets reviewed, #165 has priority because it's open for so long. Ideally, we find a common, consistent DBus concept for both of them until they are merged. |
When looking at #165 I figured it was another feature, it wasn't clear to me if this was related to the soft/forced OTA types. The end goal seems similar, so maybe we can indeed find a common, consistent DBus concept for both of them. In the meantime, I am using my own branch to avoid having soft updates applied while the system is in use (I am working on a sort of video player that is using a schedule to play pre-defined content, if a soft OTA arrives, it should be applied outside of the active schedule). Let me know if I can assist in further developments. |
|
Yeah, it's ultimately the same goal just implemented differently. When I worked on it and discussed it with the maintainers I didn't get any semantics on the soft assignment behavior, therefore we opted for download-only path and a service that could communicate separately to the server when the update is installed.
Are you sure that's what Hawkbit expects? ;) The thing is it's hardly documented anywhere expect the actual source code state machine. What do you want to return to Hawkbit in https://hawkbit.eclipse.dev/rest-api/ddi.html#tag/DDI-Root-Controller/operation/postDeploymentBaseActionFeedback ? @Bastian-Krause I'd say this PR complements mine, because "soft" rollouts are present in both, DeploymentBase and ConfirmationBase APIs. I'm still not sure what "soft" would mean in case of ConfirmationBase :) |
| gboolean send_download_authentication; /**< Send security header in download requests */ | ||
| gchar* soft_update_check_dbus_service; /**< D-Bus service name to call for soft update | ||
| permission; NULL disables the check */ | ||
| gboolean soft_update_check_force_on_unavailable; /**< if TRUE (default), proceed with the |
There was a problem hiding this comment.
I would actually prefer a safer default here, meaning false. And it looks like your commit message claims the opposite, or I'm misreading something.
There was a problem hiding this comment.
Good catch ! My first commit message was containing an error regarding the default value, it is now fixed :)
That being said, the logic I had in mind is the following:
-
If
soft_update_check_force_on_unavailableis set totrue, then a soft update could still be applied immediately upon failing to reach the service. The idea is not to block a potential critical update (one could argue that a critical update should be forced and not soft). -
Else, if set to
false, we can rely onsoft_update_check_unavailable_max_retries(if set) to still apply an update after N consecutive failures.
What do you think ?
Previously all deployments ready to install were treated as forced. Adds detection of soft actions and an optional config option to gate installation via an external D-Bus service. If the D-Bus service returns false, the update is silently deferred to the next poll cycle. Otherwise, the update is applied. An option also has been added to define fallback behavior when the service is unreachable: true = force the update (default), false = skip
When soft_update_check_force_on_unavailable is false, a permanently unreachable permission service would silently block updates forever. Add soft_update_check_unavailable_max_retries (default 0, disabled): when set to N, the client tracks consecutive poll cycles where the service is unreachable and forces the update after N failures. The counter resets when the service becomes reachable again or a new deployment is received.
71fcead to
66acaa3
Compare
HawkBit supports four rollout action types: Forced, Soft, Time Forced, and Download Only.
Before this change, the updater did not distinguish between Forced and Soft, all deployments that reached the install step were treated identically regardless of whether hawkBit signalled the update as being at the device's discretion (soft mode).
So I made the following changes to support it:
Action type detection (
src/hawkbit-client.c): The updater now infers the action type from the deployment handling fields (download/update) and logs it on each poll cycle. This makes behavior more transparent and is the foundation for type-specific handling.Soft update readiness gate: For soft updates (DDI fields download=attempt, update=attempt), the updater can optionally call IsReadyForUpdate() on a configurable D-Bus service (system bus) before proceeding. The rationale is that hawkBit's Soft semantic explicitly leaves the installation decision to the device, so it is appropriate to let another application (such as a UI or workload manager) gate the update (e.g. to defer it until the device is idle or the user has consented).
If the service returns True, the update proceeds normally.
If it returns False, the update is silently skipped; no error is reported to hawkBit, so the action remains open and the check is retried on the next poll cycle (controlled by retry_wait).
New configuration keys (
config.conf.example,include/config-file.h,src/config-file.c):Documentation (README.md): A new Soft Update Permission Check section documents the feature, the expected D-Bus interface, and the required system bus policy file.
Tests (
test/test_soft.py,test/soft_update_check_dbus_dummy.py,test/conftest.py): Six integration tests cover the full matrix of scenarios:A D-Bus dummy service (soft_update_check_dbus_dummy.py) is provided for use in tests and manual verification.