Limitations on Deployment HTTP Range Request Download #1249
Comments
|
Can anyone comment on the questions above? |
|
A comment on this issue would still be very welcome. I'd be willing to create a PR to change the ActionStatus behavior for HTTP Range Requests, but only if you tell me whether to drop ActionStatuses for this case entirely or make them configurable. |
|
@Bastian-Krause Is this still a limitation? I don't see any issue with dropping the Range Request ActionStatuses so I will change this should I end up deploying hawkbit. |
|
@MartB I did not hear back since I opened this issue and I did not see any changes relevant to these issues. A comment would be welcome. |
|
I've also hit this limitation. I think logging action status makes no sense. In general I would also say that having hawkbit serve the range requests would be best avoided. Ideally there would be a way to provide an URL to a CDN service, to keep the application server out of the loop. |
When HawkBit is used to stream chunked deltas through RAUC adaptive updates, adding a database entry for each 4KB block that is requested makes no sense. Fixes: eclipse#1249 Signed-off-by: Zygmunt Krynicki <me@zygoon.pl>
HawkBit creates ActionStatus entries for each GET request associated with an artifact of an assigned software module. Amongst others, this severely breaks RAUC block-based adaptive updates [1], which issue a flurry of range requests for small chunks, so that the whole image does not have to be streamed in case of incremental system changes. [1] https://rauc.readthedocs.io/en/latest/advanced.html#block-based-adaptive-update-block-hash-index Fixes: eclipse#1249 Signed-off-by: Zygmunt Krynicki <me@zygoon.pl>
HawkBit creates ActionStatus entries for each GET request associated with an artefact of an assigned software module. Amongst others, this severely breaks RAUC block-based adaptive updates [1], which issue a flurry of range requests for small chunks, so that the whole image does not have to be streamed in case of incremental system changes. [1] https://rauc.readthedocs.io/en/latest/advanced.html#block-based-adaptive-update-block-hash-index Fixes: eclipse#1249 Signed-off-by: Zygmunt Krynicki <me@zygoon.pl>
Hi,
we are using hawkBit with RAUC in rauc-hawkbit-updater. In a recent PR, streaming installation of update bundles is implemented: rauc-hawkbit-updater passes the authentication header and the hawkBit deployment download URL to RAUC. RAUC performs HTTP Range Requests (~128 KB range per request, due to NBD reads per squashfs block, see RAUC's streaming docs) while installing the update bundle.
While testing this, I hit these hawkBit errors:
That means hawkBit's default configuration limits HTTP Range Requests effectively to ~1000 requests per action and 200 requests per second. For the time being, I disabled both limitations via:
While this works, I am not so sure if this is the desired approach for our use case. What do you think?
Furthermore, one ActionStatus entity per Range Request is generated, meaning a medium sized update bundle of 150 MB generates >1000 ActionStatuses when requested in 128 KB chunks. Could you elaborate why hawkBit needs to generate an ActionStatus per Range Request? I could not find reasoning in the commits/PRs. Could these Range Request ActionStatuses be dropped maybe? Or made configurable somehow?
The text was updated successfully, but these errors were encountered: