eclipse
feat: allow a target to set offline assigned distribution set
Hello, This PR allows a target to update it's assigned version (fix: https://github.com/eclipse/hawkbit/issues/446).
It's relies on https://github.com/eclipse/hawkbit/pull/563 but allow a target to do that it self instead of using Management API.
why :
- allow to know a target version before first update (eg: after flashing)
- allow offline rollback mechanism
Related discussion: https://github.com/eclipse/hawkbit/issues/242
@avgustinmm would you be able to review this PR soon ?
@flobz thanks for your contribution.
By coincidence, I was reviewing the PR at the same time you wrote. Though I added many comments into my review they are, in general, mostly related to same thing - not exposing backend management service methods to controller permissions.
I have some questions regarding the motivation of the PR. If the target requests a rollback I suppose the scenario would be something like:
- Deploy software, but it is detected as not working
- Device keeps a record about the previous version
- It update/set offline assignment -> it creates install actions
- then it queries as it always does for updates and the same update it has requested is triggered
However, I'm not sure how "allow to know a target version before first update (eg: after flashing)" would work? Device, at the step 4 (above), should "realize" that its initial version is the same that has been assigned to it and will not install it but will just feedback that it is installed without actually installing it?
I'm still not sure these are real usecases. Isn't it up to a backend service, responsible for device management, to provision installed ds info and to "realize" error states and to launch recover/rollback actions?
And finally - since this is an DDI API method it shall be very stable so it is very important the path of the method. At the moment I'm not sure installedBase is a proper path.
Device, at the step 4 (above), should "realize" that its initial version is the same that has been assigned to it and will not install it but will just feedback that it is installed without actually installing it?
In the case where no version is assigned to the target because we don't want to update it, it's nice to know it's version no ?
I'm still not sure these are real usecases. Isn't it up to a backend service, responsible for device management, to provision installed ds info and to "realize" error states and to launch recover/rollback actions?
In my opinion a target should be autonomous. We use rauc with two slot so, for example if one slot is corrupt target should automatically switch to the other slot and tell hawkbit that the installed version isn't anymore the version on the corrupt slot but version on the healthy slot.