eclipse
Artifact availability to targets (non-rollout)
Hello,
I am implementing diffed OTA updates for a project, using Hawkbit and SWUpdate. I am in need of a storage solution that accepts multipart range requests.
To perform diffed updates with these two services, an update file (.swu file for SWUpdate) refers to a separate artifact storage location, for the chunked and hashed file, that accepts multipart range requests. Those requests are used to download the image differences from what's installed.
I decided to see if Hawkbit could host the chunked file, since it's already hosting and rolling out the .swu. So far, I haven't found a way to assign software modules to targets for them to download the chunked file over the DDI API. I tried by generating a rollout, but with a rollout, specific update files are required (an .swu file for swupdate), and the rollout of the chunked artifact immediately fails and the artifact becomes no longer available to targets over the DDI API. I also attempted direct assignment of a distribution set, but that doesn't appear to make the artifact available over the DDI API.
Does anyone in this maintaining community know if this operation is supported?
Thanks for your help.
Hi, AFAIK, hawkbit support range based download. However, what I understand is that, you need to install diff, e.g. you have installed 1.0 and to install 1.1 you want do assign 1.0to1.1diff. Hawkbit does not directly support such concept. However, it support tooling for implementing that. You could create rollouts/autoassignments like:
- on targets with 1.0 (rsql filter) -> install 1.0to1.1diff
- on other (rsql filter) -> instal 1.1
However, to do so, you should first have support in the client - i.e. the client shall somehow "discover" that it is a diff and apply it properly.
@avgustinmm thanks,
Yes, there may be some update processes that take a diff between two images (1.0 -> 1.1) and assign only the diff between them. However, the method that SWUpdate uses is a client-controlled delta update, leveraging multipart byte range requests. SWUpdate is able to compare, for example, a chunked and hashed disk image to a chunked and hashed image hosted in the cloud. As SWUpdate compares chunk hashes that exist on-disk and hashes that exist in the cloud, it requests only the file byte ranges for chunks whose hash differs from what's on-disk. This way, the cloud update management service doesn't have to create delta updates for every possible version-to-version update.
For a SWUpdate delta update, there are two artifacts - the "update" artifact, and the "chunked image" artifact. The "update" artifact contains instructions for conducting the update, including the chunk hash header for the "chunked image". The "update" artifact can be delivered to the target as a typical Hawkbit rollout. However, the "chunked image" needs to be available to the target while not forcing the target to download it. The "update" artifact contains a URL to the "chunked image" so the target knows where to download chunks from.
To enable this type of update for SWUpdate, all that is required is that the chunked image can be hosted in some artifact storage, available to the target, that supports multipart byte range requests. I noticed here in the hawkbit docs that "Delta artifact hosting [is] supported." I'm assuming this is what you're referring to, where the artifact itself is the delta, as opposed to the client being able to perform it's own delta comparison and grab segments that it needs.
The problem I encounter with Hawkbit is:
- To make a "delta" artifact available to a target to download, I have to assign the artifact to the target in a rollout
- Once assigned in a rollout, the client can't differentiate between an "update" artifact and a "delta" artifact
- The client tries to download the "delta" artifact, expecting it to be an update package, and fails
- The "delta" artifact then becomes inaccessible to the target because the rollout failed
Does the problem I'm encountering make sense? Does Hawkbit support this type of general artifact availability?
The only entirely hawkbit solution I see at the moment is to have a distribution with one software module with 2 artifacts (or 2 software modules with single artifact each) with->
- update artifact - which is the file with "instructions"
- chunked image artifact - which, being a software module artifact will be downloadable, including with range request support In order to user hawkbit just like a file server for this update - you could even have the second artifact as part of completely different artifact in a software module not in assigned distribution set. Linking of the "chunked image artifact" could be a little bit complex if separated - i.e. proper url, authentication and so on ...
Could be helpful w.r.t. delta update functionality: https://github.com/eclipse-hawkbit/hawkbit/issues/331#issuecomment-3164417969
