-
Notifications
You must be signed in to change notification settings - Fork 191
Separation of Download and Install
Many users have the need for a separation of download and update operation. Example use cases could be defined maintenance windows or required user interaction, e.g. "An update is ready for installation? Do you want to start?". Expected in all of these scenarios is that the update on the device goes as fast as possible thus removing the long running download part (especially on constraint networks) helps.
In order to achieve that functionality we should:
- Introduce a new Action.Status
DOWNLOADED
. - Create actions with a new
UpdateType
handling parameter similar to the existing Action.ActionType. I would go for the followingUpdateType
s: - RUN (the old variant, default)
- WAIT (the new two phase variant.)
- AFTER xxxxx (time based switch similar to soft/forced)
- Actions with that option are on hold at
DOWNLOADED
until theUpdateType
is set toRUN
, i.e. I would not intruduce an extra "go for it" command but instead make simply the switch of the option. Again similar for soft/forced.
DDI has already an separation defined in the deploymentBase
resource.
The action should start with:
{
"deployment" : {
"download" : "forced",
"update" : "skip",
As soon as the action moves on the switch of the update field is promoted to the device. This will happen similar to the attempt
to forced
switch on the same resource/action. As it is with that existing switch we will change the GET URI of the deploymentbase
in the root polling resource to enforce new etag generation so the device knows that something has happened (e.g. https://HOST/TENANT_ID/controller/v1/CONTROLLER_ID/deploymentBase/1?c=-2130877640
switches to https://HOST/TENANT_ID/controller/v1/CONTROLLER_ID/deploymentBase/1?c=-2130877641
Result will than be:
{
"deployment" : {
"download" : "forced",
"update" : "forced",
I propose to keep the download information in the body in case a device missed the download command.
However, the switch of the action to DOWNLOADED
is triggered by the device so in DDI case the device would report back based on a new execution state:
{
"id" : "3",
"time" : "20140511T121314",
"status" : {
"result" : {
"finished" : "none"
},
"execution" : "downloaded",
"details" : [ "I am done with downloading" ]
}
}
For the event from Update Server to DMF client we could use the existing DOWNLOAD_AND_INSTALL
message body. However, we have to introduce a new topic
header value: DOWNLOAD
.
For the actionStatus feedback message we could use a new ActionStatus value DOWNLOADED
which results into a corresponding switch in the repository.
As soon as the update is confirmed we sent out DOWNLOAD_AND_INSTALL
message again. As with DDI I would not go for an extra/new 'INSTALL' message for maximum robustness, i.e. if somehow the device lost the confirmed/downloaded artifacts it still gets the full information package. This should never happen of course but as always with software update for devices we hope for the best but design for the worst 😄
The functionality needed here is similar to the soft/forced switch by means that it is possible to define the UpdateType
at action creation time (both single deployment and rollout) and switch that later on at runtime of the action.
Management API and UI should allow to filter targets on the action state DOWNLOADED
. Currently that is only possible with defined target filters.
I would propose to keep forced/soft option only once per action. DDI allows to define those separately, e.g.
{
"deployment" : {
"download" : "attempt",
"update" : "forced",
However, I think we made a mistake back then. We have to keep the API stable but I would go at least for the initial implementation to have both either attempt
or forced
based on the definition of the action as it is today.
We have multiple stages here:
Rollout management does not care about the new functionality by means you can set UpdateType
in the rollout as with soft/forced today but group progress calculation continuous to consider only fully completed updates. It will simply take more time as an operator by Mgmt API/UI has to confirm the update. No harm done, everything just works 😄
Rollout management considers for threshold computation also the DOWNLOADED
state, e.g. you can configure that the switch to the next group should be at 50% updated OR 80% downloaded. This can even be used if the actions are created with RUN
, i.e. it is sufficient that rollout management is aware of the new state DOWNLOADED
. That allows rollout management to fulfill its role of managing the system load but does not help with the whole maintenance window idea.
This does not belong here but rollout management could do a lot more than it does today. For the topic at hand it could for instance perform the switch to update per group (both time or threshold based). For example you have 10 maintenance windows and based on that you create a rollout with 10 groups, one per maintenance window. I would recommend to keep that out of the discussion for the time being though.
Eclipse hawkBit
Project Page