feat: allow a target to set offline assigned distribution set

[flobz]

Hello,
This PR allows a target to update it's assigned version (fix: #446).

It's relies on #563 but allow a target to do that it self instead of using Management API.

why :

1. allow to know a target version before first update (eg: after flashing)
2. allow offline rollback mechanism

Related discussion:
#242

[hawkbit-bot]

Can one of the admins verify this patch?

[flobz]

@avgustinmm would you be able to review this PR soon ?

[avgustinmm]

could use lombok annotations already available hawkbit wide

@Data@ToString
@ToString 

and to remove some boilerplate code

[flobz]

Lombok isn't in hawkbit-ddi-api dependencies, you want to add it ?

[avgustinmm]

not sure about if the enpoint shalle be installed_base_action ...
have to think over it

[flobz]

Have you an answer now ? So we can freeze the API definition.

[avgustinmm]

Not yet. We are up to release 0.5.0. After that we will have enough time to think about that DDI API change ...

[avgustinmm]

@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:

1. Deploy software, but it is detected as not working
2. Device keeps a record about the previous version
3. It update/set offline assignment -> it creates install actions
4. 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.

[flobz]

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.

[lizziemac]

Seconded - I'm also using a 2-partition layout for updates, as well as a recovery mode that flashes a "golden image" to both partitions in certain scenarios.

It's important for the device to be the source of truth because even the best backend can't handle all error cases.

In the past week I've encountered two issues where the device was on a different version than hawkbit thought

• The device "failed" to update, however when I checked what version it was on,it was on the newly assigned DS (that failed)
• When going into recovery mode and reflashing with the golden image on both partitions, the device in hawkbit inaccurately reflected the previous version, instead of the golden version