🚀 New features
OpenApi (Swagger) support
This feature enables our Management API and Direct Device Integration API to be available in the newly integrated Swagger
- Introduce swagger support in #1432
- Make the OpenApi configuration conditional in #1437
- Additional example values in #1441
- Add bearer auth for Management API in #1468
Retry of a Rollout
This new feature enables a rollout to be retried only over failed targets after being completed.
- Introduce Retry rollout in #1454
More Features
- Extend System Configuration to support Default Distribution Set Type(#1457)
- OICD Pluggable permission mapper (#1469)
- OpenApi Doc generation (#1442)
- Remove Spring Rest Doc (#1446)
🚀 Features included in milestone releases
User Consent Flow
This new feature facilitates the implementation of user consent requirements (e.g. as mandated by the European Tangible Goods Directive) by enhancing the action state machine with a new state WAITING_FOR_CONFIRMATION. Whenever a new deployment action is initiated (e.g. through a rollout or a manual assignment), it needs to be confirmed first before it enters the state RUNNING. If the confirmation is rejected, the action continues to be in state WAITING_FOR_CONFIRMATION until it is confirmed at a later point in time or cancelled. To accept or reject a pending confirmation, device implementors can use the Direct Device Integration API (DDI) or the Device Management Federation API (DMF). In case of DDI, a new "confirmationBase" resource has been introduced providing the information about pending confirmations and the associated updates. For DMF, a new "CONFIRM" message has been introduced, informing the target device about open confirmations.
In addition, a target device can also be set into an auto-confirm state to indicate that all future actions of this device shall be confirmed automatically. This enables two use cases: Operators might want to disable the confirmation phase for specific test devices, whereas end-users might want to enable automatic updates and give their consent for all future updates (until revoked). The auto-confirm state can either be set by target devices via DDI and DMF, or by operators via Management API and UI.
This feature was contributed by @dimitar-shterev, @strailov, @ramannas, and @herdt-michael in #1293
- Support user consent flow by @herdt-michael in #1293
Target Types
By default, all targets are compatible to all distribution sets. This means, every valid distribution set, that has the required software modules assigned, can be assigned for installation to all available targets. However, some targets might not support the content of the distribution set, but the assignment of it is possible with Eclipse hawkBit, nevertheless. To avoid such wrong assignments and for the sake of user guidance, it is possible to restrict the general compatibility using target types and define for presumably different types of targets the specific types of distribution sets that they are compatible with.
- Feature target type filter by @aktivk in #1197
- Feature target with target type in UI by @aktivk in #1178
- Feature - TargetType compatibility check by @singrob in #1180
- Implement target type CRUD UI operations by @vkandrotas in #1184
- Feature target type entity by @aktivk in #1162
Manually Trigger the Next Rollout Group
This new rollout feature gives you more flexibility in controlling the execution of your rollout groups. Typically, the cascaded execution of rollout groups is controlled by the so-called "trigger threshold". The trigger threshold specifies a percentage of target devices which have finished their installation of the assigned firmware update. When the trigger threshold is exceeded, the next rollout group will be executed.
There are cases, however, when the trigger threshold of a rollout group is never met, for example, if too many target devices are offline. As a consequence, the execution of your rollout, in particular the execution of the remaining rollout groups, might be stuck. To overcome this state, you can now manually trigger the next rollout group, without waiting for the trigger threshold to be reached. The new feature is offered as part of the Management API and Management UI.
- Trigger next rollout group - backend and management API implementation by @dimitar-shterev in #1294
Management API: New Resource Collection /rest/v1/actions
This new Management API feature provides read-only access to the collection of deployment actions via the context path "/rest/v1/actions". Furthermore, it allows you to filter this collection in a very flexible way by defining FIQL queries (request parameter 'q'). For example, you can define the following queries:
- Find all actions that match a certain action status (e.g. downloaded, finished, error, scheduled etc.).
- Find all actions that were spawned by a certain rollout.
- Find all actions that failed with a certain status code.
- Find all actions that refer to a certain distribution set.
So far, the collection of deployment actions could only be accessed for a specific target device ("action history"). With this new API, you can retrieve the data that is relevant for your specific scenario and feed it into your own custom UIs (e.g. dashboards) to monitor and troubleshoot your firmware updates.
- Add resource collection /rest/v1/actions to Management REST API by @stefbehl in #1299
- Management API: Allow to filter actions by last status code by @stefbehl in #1311
- Add new endpoint for single action by @strailov in #1316
DDI-API: InstalledBase
Installed Base is a new feature which extends the DDI API with the "installedBase" endpoint that behaves similar to "deploymentBase" but instead of providing the latest on-going assignment, it provides the latest installed Distribution Set information. It can be used in multiple scenarios of a factory reset, device sync, etc.
Support for Action Status Codes
This new feature enables targets to optionally include a status code into their action status feedback messages that are sent to Eclipse Hawkbit. The feature is supported via DDI and DMF. Annotating action status entries with status code simplifies the troubleshooting of software updates, e.g. by detecting error clusters matching a specific status code.
- Introduce action status scoped custom code by @herdt-michael in #1277
- Introduce action status scoped custom code - part 2 by @stefbehl in #1281
- Adding last action status code in view Rolloutgroup targets by @blomark in #1295
- Management API: Allow to filter actions by last status code by @stefbehl in #1311
- Management API: Expose lastStatusCode property of action entities by @stefbehl in #1313
More features 🚀
- Additional tag filtering by targetId and distributionSetId (#1381)
- Filter Distribution sets by assigned Software modules (#1386)
- Add statistics for Distribution set (#1388)
- Extend get Module artifacts API by download url (#1390)
- Batch system configuration update (#1402)
- Extend Rollout filtration fields with status and Distribution set (#1380)
- Optional controller attributes for THING_CREATED by @bogdan-bondar (#1154)
- PostgreSQL support (#932)
- Mgmt API accepts and returns SHA256 file hash (#918)
- OpenID Connect support (#865)
- DDI supports SHA256 (#869)
- CORS support for Mgmt API (#854)
- Support for Multi-Assignments #833
- Add multi-user support #829
- Feature download only #810
👍🏻 Improvements
- Switching license from EPL v1 to v2 (#1427)
- Replace Jetty with Tomcat as web server (#1379)
- Refactoring TargetFilterQueryManagement (#1108)
- Refactor AutoAssignExecutor to improve the extensibility (#1110)
- Set DdiActionFeedback ID deprecated (#1091)
- Align target queries to only use specifications (#1148)
- Introduce new tenant configuration events (#1059)
- Improved check whether a distribution set is valid (#1064)
- Show Controller ID within target, filter and rollouts view (#1056)
- Added triggeredBy for rollouts and autoassignment (#1017)
- Increase the value of maximal targets per auto assignment (#910)
- Performance optimizations for Multi-Assignments (#858)
- Increase target name to 128 and target controller id to 256 (#849)
⬆️ Version upgrades
🐞 Bugs fixed
- Enforce decoding on authentication check (#1362)
- Fix error for downloading soft deleted artifact binary (#1102)
- Fix null pointer exception in rsql target field validation test (#1172)
- Fix installedBase link in DDI base resource (#1232)
- Fix NPE that occurs on invalid user input in editfields (#1077)
- Non-existing targets are not added to assignment count (#919)