b69bedd8f9
* DDI API: Limit number of feedback messages for an action status. Even though the number of ActionStatus entries are limited to 1000 per action using QuotaManagement, there is no limit on the number of messages that can be sent as part of a single ActionStatus. This allows a controller to potentially send large number of messages for a single action. Limiting the number of allowed messages to 50 using the javax.validation.constraints.Size within DdiStatus. Signed-off-by: Christian Storm <christian.storm@siemens.com> Signed-off-by: Himanshu Kumar Singh <himanshu.singh@siemens.com> Signed-off-by: Raju HS <raju.hs@siemens.com> * DDI API: Extend API response to retrieve controller feedback. (#381) Resolves #381 The mechanism is useful for example, when the client software running on the device loses this information prior to reporting a final execution status such as 'closed' to hawkBit. This may happen, e.g., due to a power cycle or simply a crash. Upon the client software restarting, it installs the same payload again as advertised by hawkBit (as the device has not sent a final update execution status). Instead, if the last feedback sent to hawkBit would be reported back to the device, the client may resume installation. Feedback messages sent as part of POST /{tenant}/controller/v1/{targetid}/deploymentBase/{actionId}/feedback, are sent back to controller as part of response to GET /{tenant}/controller/v1/{targetid}/deploymentBase/{actionId}. Following example illustrates the API changes: 1. After retrieving the action from server, controller starts download and sends a feedback. curl 'http://127.0.0.1:8080/default/controller/v1/1/deploymentBase/1/feedback' -i -X POST -H 'Content-Type: application/json;charset=UTF-8' -H 'Accept: application/hal+json' -d '{ "id" : "1", "time" : "20170406T121500", "status" : { "result" : { "progress" : { "of" : 1, "cnt" : 0 }, "finished" : "none" }, "execution" : "proceeding", "details" : [ "proceeding with download" ] } }' 2. Once artifact download has finished, controller sends another feedback. curl 'http://127.0.0.1:8080/default/controller/v1/1/deploymentBase/1/feedback' -i -X POST -H 'Content-Type: application/json;charset=UTF-8' -H 'Accept: application/hal+json' -d '{ { "id" : "1", "time" : "20170406T123000", "status" : { "result" : { "progress" : { "of" : 1, "cnt" : 0 }, "finished" : "none" }, "execution" : "proceeding", "details" : [ "downloaded artifacts for update" ] } }' 3. If there is a power outage now, the controller can retrieve the messages posted earlier from the action history when it restarts again. curl 'http://127.0.0.1:8080/default/controller/v1/1/deploymentBase/1?c=411599879&actionHistory=-1' -i -H 'Accept: application/hal+json' Response will be like below { "id": "1", "deployment": { "download": "forced", "update": "forced", "chunks": [ { "part": "os", "version": "1", "name": "1", "artifacts": [....], } ], }, "actionHistory": { "status": "RETRIEVED", "messages": [ "downloaded artifacts for update", "proceeding with download" ] } } 4. Based on the feedback messages, controller may be able to skip the download and resume with installation and send additional feedback. curl 'http://127.0.0.1:8080/default/controller/v1/1/deploymentBase/1/feedback' -i -X POST -H 'Content-Type: application/json;charset=UTF-8' -H 'Accept: application/hal+json' -d '{ "id" : "1", "time" : "20170406T121314", "status" : { "result" : { "progress" : { "of" : 1, "cnt" : 0 }, "finished" : "none" }, "execution" : "resumed", "details" : [ "resuming installation based on previous feedback, download skipped" ] } }' Note: The maximum number of messages to be retrieved from the database by a controller is limited to 100. The actionHistory parameter's value has the following meaning: Input Value | Output ----------------------------- <0 | Retrieve maximum allowed number of messages from | action history. unspecified or =0 | Do not retrieve any message (default). >0 | Retrieve specified number of messages, limited by | maximum allowed number. Signed-off-by: Christian Storm <christian.storm@siemens.com> Signed-off-by: Himanshu Kumar Singh <himanshu.singh@siemens.com> Signed-off-by: Raju HS <raju.hs@siemens.com>
hawkBit metadata repository
The repository is in charge for managing the meta data of the update server, e.g. provisioning targets, distribution sets, software modules etc.
Build
[indent=0]
$ mvn clean install
Note, in order to build correctly in your IDE, you have to add ./target/generated-sources/apt to your build path.
#Concepts
Rollout
A rollout consists of the distribution set and a target-query-filter which defines the targets to be updated in this rollout. The targets within this filter are split up in configured amount of Deployment Groups at creation time.
When starting a rollout, for all targets within this rollout deployment actions will be created. The deployment actions of the first group will be started immediately all other deployment actions will be scheduled.
Due rollouts might include a large number of targets and deployment group, creation as well as starting a rollout might take some time and therefore the creation and starting of an rollout is executed asynchronously. The creation and starting progress is reflected by the rollout's status attribute
Rollout Creation
The targets reflected by the target-query-filter is interpreted at creation time. Only targets which have been created at that time are included in the rollout. Targets which are created after the rollout creation will not be included. At rollout creation time all necessary deployment groups containing the targets will be created. Dynamically adding targets to a created or running rollout is currently not supported.
Rollout Starting
The rollout is using the same concept based on deployment acionts per target. All necessary deployment acionts will be created at starting point but not all deployment acionts will be set to running. Only the deployment acionts of the first deployment group is set to running, all other actions are created in scheduled state.
If targets having not finished deployment actions at rollout starting time, these action are tried to cancel (state: canceling). Scheduled actions from another rollout are canceled directly on server side because they were never running before and can be safely canceled.
Multiple rollouts can be running at the same time, but if the rollouts effect the same targets they will interfer the targets deployment actions e.g. canceling/cancel already running/scheduled deployment actions.
Deployment Group Condition/Action
Success Condition/Action
A success condition defines when a deployment group is interpreted as success and triggers the success action. E.g. a threshold of successfully updated targets within the group.
The success action is executed if the success_condition is fullfilled. Currently only the success action starting the next following deployment group is available.
Error Condition/Action
A error condition defines when a deployment group is interpreted as failure and triggers the error action. E.g. a threshold of update failures of targets within the group.
The error action is executed if the error condition is fullfilled. Currently only the error action pausing the whole rollout is available, a paused rollout can be resumed by a user.
Rollout Scheduler
The rollout is managed by a scheduler task which is checking for rollouts in running state. This is done atomic by updating the row in the database, so only the rollouts are checked and processed for the current instance to avoid that multiple instances are processing a rollout.
Due the scheduler, it might take some time until a rollouts is processed and switching is state or starting the next deployment group.