lingwei.kong/hawkbit
1
0
Fork 0
Code Issues Pull Requests Actions 3 Packages Projects Releases Wiki Activity

Remove multi_assignments from documentation (#2910)

Browse Source 
Signed-off-by: strailov <Stanislav.Trailov@bosch.io>
This commit is contained in:
Stanislav Trailov
2026-02-09 16:09:04 +02:00
committed by GitHub
parent a0e8c411c8
commit 51f1de54f4
1 changed files with 0 additions and 39 deletions
Download Patch File Download Diff File Expand all files Collapse all files

39
docs/rollout-management.md
View File

@@ -57,42 +57,3 @@ The cascading execution of the deployment groups is based on two thresholds that
</p>
---
## 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.