9cb5d31396
* Updating the schema for targetfilterquery and rollout * Updating the weight validation logic and tests * Make weight optional * Fix existing multi assignment tests by adding weight, remove weight from TargetFilterQuery * Add weight validation tests, fix tests * Add mgmt api tests for assignment and getting action with weight * Add management layer validation and tests for creating rollouts with weight * Fix amqp test, add repo level validation to resource tests * Add weight to rollout mgmt-api and tests * Add weight to mgmt api target Filter create and update * Add target filter auto assign weight. disable enforcement of setting a weight in multiassign mode * Remove ignored tests, fix api doc * Fix minor findings * Fix findings * Remove hardcoded min weight * Add docu text, fix findings * Fix api documentation * Expose weight via DMF * Expose actions according to weight via ddi * Fix documentation * Add method to get actions ordered by weight to deploymentManagement * Updating the schema for targetfilterquery and rollout * Updated the indentation * Updated the helper class, fixed the randomUID in test factory * Updated the class name with prefix JPA * Adding the missing License for WeightValidationHelper class * Adding documentation to the dmf api on weight * Removed the merger markers * Updated the class name * Removed the redundant method * Addressed final PR comments * Updated the missing testcase with latest default weight value * Reverting the default value of weight back to 1000 and updated tests Signed-off-by: Shruthi Manavalli Ramanna <shruthimanavalli.ramanna@bosch-si.com> Signed-off-by: Stefan Klotz <stefan.klotz@bosch-si.com>
4.3 KiB
title, parent, weight
| title | parent | weight |
|---|---|---|
| Rollout Management | Concepts | 54 |
Software update operations in large scale IoT scenarios with hundreds of thousands of devices require special handling.
That includes:
-
Technical Scalability by means of horizontal scale of the hawkBit server cluster in the cloud.
-
Global artifact content delivery capacities.
-
Functional Scalability by means of:
- Secure handling of large volumes of devices at rollout creation time.
- Monitoring of the rollout progress.
- Emergency rollout shutdown in case of problems on to many devices.
-
Reporting capabilities for a complete understanding of the rollout progress at each point in time.
Eclipse hawkBit sees these capabilities under the term Rollout Management.
The following capabilities are currently supported by the Rollout Management:
-
Create, update and start of rollouts.
- Selection of targets as input for the rollout based on target filter functionality.
- Selection of a DistributionSet.
- Auto-splitting of the input target list into a defined number deployment groups.
-
Approval workflow
- Has to be enabled explicitly in configuration.
- Enables a workflow that requires a user with adequate permissions to review any new or updated rollout before it can be started.
- Allows integration with 3rd party workflow engines.
-
Cascading start of the deployment groups based on installation status of the previous group.
-
Emergency shutdown of the rollout in case a group exceeds the defined error threshold.
-
Rollout progress monitoring for the entire rollout and the individual groups.
Cascading Deployment Group Execution
The cascading execution of the deployment groups is based on two thresholds that can be defined by the rollout creator.
- success condition by means of percentage of successfully installed targets in the current groups triggers.
- error condition by means of absolute or percentage of failed installations which triggers an emergency shutdown of the entire rollout.
Rollout state machine
State Machine on Rollout
State Machine on Rollout Deployment Group
Multi-Assignments (beta)
One of the main paradigms of Eclipse hawkBit is, that a Distribution Set represents the currently installed software of a device. Hence, a device can have only one Distribution Set assigned/installed at a time. With Multi-Assignments enabled, this paradigm shifts. Multi-Assignments allows to assign multiple Distribution Sets to a device simultaneously, without cancelling each other. As a consequence, an operator can trigger multiple campaigns addressing the same devices in parallel.
Action weight
To differentiate between important and less important updates a property called weight is used. When multi-assignments is enabled every action has a weight value between (and including) 0 and 1000. The higher the weight the more important is the assignment represented by the action. Also when defining a rollout or an auto-assignment and multi-assignments is enabled a weight value has to be provided. This value is passed to the actions created during the execution of these rollouts and auto-assignments. If no weight was provided the highest value of 1000 is used instead.
Consequences
While this feature provides more flexibility to the user and enables new use-cases, there are also some consequences one should be aware of:
Critical
- This feature is in beta and may change unannounced.
- For now, this feature is opt-in only. Once activated, it cannot be deactivated.
Minor
- While on DMF-API a MULTI_ACTION request is sent, DDI-API only exposes the next action which has the highest priority in the list of open actions(according to their weight property).
- All information regarding the currently assigned or installed Distribution Set does only respect the last assignment, as well as the last successfully installed Distribution set. This also affects:
- Pinning a target or Distribution Set in Deployment View.
- Statistics about installed or assigned Distribution Sets.
- Auto close running actions, when a new Distribution Set is assigned (
repository.actions.autoclose.enabled) is deactivated. - Marking a Distribution Set to be a Required Migration Step is deactivated.