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 following UpdateTypes:
• 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 atDOWNLOADED until the UpdateType is set to RUN , 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.

Impact on the interfaces:

DDI

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=-2130877640switches 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" ]
  }
}

DMF

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 😄

Management UI and API

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.

Impact on Soft/Forced switch.

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.

Impact on Rollout Management

We have multiple stages here:

Rollouts don't care

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 😄

Rollouts know about DOWNLOADED

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.

Rollouts do everything

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.