* added methods to unassign by multiple controller ids
* deprecated toggle assigments - too complex to undestand
* deprecated unassign (management) of single controller id - in favour of methods with controller ids
Signed-off-by: Marinov Avgustin <Avgustin.Marinov@bosch.com>
Adding a method with:
* optimized payload - just controller ids
* no response payload - not needed for that use-case
* targeting - thousands of targets tagged at once
Signed-off-by: Marinov Avgustin <Avgustin.Marinov@bosch.com>
This functionallity seems to get via AMQP (after some authentication)
a private (wihtout need of authentication) url to an artifact assigned
to the controller.
By default, DDI or DMF shall provide proper urls (for direct download)
to devices and if they have to be without authentication this shall be
solved in different ways - for instance separate download server providing
dedicated private / signed urls.
This functinallity is not a real hawkBit part but more like something
intended to solve some edge cases.
Since it is complicated, heeds support, doesn't solve wide spread use
cases, and could be achieved with other means - better to be removed.
Signed-off-by: Marinov Avgustin <Avgustin.Marinov@bosch.com>
1. Add support in REST and Mgmt API for dynamic group template
2. If present - groups follows the pattern of this template, otherwise - the last static group
3. This allows to create pure dynamic rollout with 0 static groups - auto assignment equivalent with groups
Signed-off-by: Marinov Avgustin <Avgustin.Marinov@bosch.com>
* adds PUT method for updating name and description of a rollout
* restrict RolloutUpdate to changing only name and description
* small refactoring
Signed-off-by: Marinov Avgustin <Avgustin.Marinov@bosch.com>
Before REST refactoring MgmtBaseEntity was able to deserialize fields
like createdBy. After refactoring, with READ_ONLY access it was dropped
and these fields become null. While this could be a good change, it is
not backward compatible (is that needed) and most importantly will lead
to the fact that Feign client won't be able to access that
data. So, at least for now, I return deserialization back
Signed-off-by: Marinov Avgustin <Avgustin.Marinov@bosch.com>
When spring restdoc was replaces with swagger & open api some info was lost
This commit returns back this info for Mgmt API - Tenant
Signed-off-by: Marinov Avgustin <Avgustin.Marinov@bosch.com>
* REST doc / Mgmt Target Tag - fix missed info
When spring restdoc was replaces with swagger & open api some info was lost
This commit returns back this info for Mgmt API - Target Tag
Signed-off-by: Marinov Avgustin <Avgustin.Marinov@bosch.com>
* REST doc / Mgmt Target Type - fix missed info
When spring restdoc was replaces with swagger & open api some info was lost
This commit returns back this info for Mgmt API - Target Type
Signed-off-by: Marinov Avgustin <Avgustin.Marinov@bosch.com>
---------
Signed-off-by: Marinov Avgustin <Avgustin.Marinov@bosch.com>
When spring restdoc was replaces with swagger & open api some info was lost
This commit returns back this info for Mgmt API - Target Tag
Signed-off-by: Marinov Avgustin <Avgustin.Marinov@bosch.com>
When spring restdoc was replaces with swagger & open api some info was lost
This commit returns back this info for Mgmt API - Targets
Signed-off-by: Marinov Avgustin <Avgustin.Marinov@bosch.com>
When spring restdoc was replaces with swagger & open api some info was lost
This commit returns back this info for Mgmt API - TargetFilters
Signed-off-by: Marinov Avgustin <Avgustin.Marinov@bosch.com>
When spring restdoc was replaces with swagger & open api some info was lost
This commit returns back this info for Mgmt API - SoftwareModules Types
Signed-off-by: Marinov Avgustin <Avgustin.Marinov@bosch.com>
When spring restdoc was replaces with swagger & open api some info was lost
This commit returns back this info for Mgmt API - SoftwareModules
Signed-off-by: Marinov Avgustin <Avgustin.Marinov@bosch.com>
When spring restdoc was replaces with swagger & open api some info was lost
This commit returns back this info for Mgmt API - Rollouts
Signed-off-by: Marinov Avgustin <Avgustin.Marinov@bosch.com>
When spring restdoc was replaces with swagger & open api some info was lost
This commit returns back this info for Mgmt API - DistributionSetsTags
Signed-off-by: Marinov Avgustin <Avgustin.Marinov@bosch.com>
When spring restdoc was replaces with swagger & open api some info was lost
This commit returns back this info for Mgmt API - DistributionSetsTags
Signed-off-by: Marinov Avgustin <Avgustin.Marinov@bosch.com>
When spring restdoc was replaces with swagger & open api some info was lost
This commit returns back this info for Mgmt API - DistributionSets
Signed-off-by: Marinov Avgustin <Avgustin.Marinov@bosch.com>
When spring restdoc was replaces with swagger & open api some info was lost
This commit returns back this info for Mgmt API - Actions
Signed-off-by: Marinov Avgustin <Avgustin.Marinov@bosch.com>
When spring restdoc was replaces with swagger & open api some info was lost
This commit returns back this info for DDI API
Signed-off-by: Marinov Avgustin <Avgustin.Marinov@bosch.com>
* [#1383] Spring Boot 3 migration Step 2
Some of the steps:
1. Change spring version parent and versions in root pom.xml
2. update eclipselink versions
3. javax.annotation -> jakarta.annotation (*.java)
4. javax.persistence -> jakarta.persistence (*.java)
5. javax.servlet -> jakarta.servlet (*.java, pom.xml)
6. javax.validation:validation-api -> jakarta.validation:jakarta.validation-api (pom.xml)
7. javax.validation -> jakarta.validation (*.java)
8. javax.transaction -> jakarta.transaction (*.java)
9. replace spring-cloud-stream-binder-test (hawkbit-repository-test) with
```
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-stream-test-binder</artifactId>
</dependency>
```
, TestSupportBinderAutoConfiguration.class }) -> })
@Import(TestChannelBinderConfiguration.class)
10. Set to Simple UI standard parent
11. requestMatchers to securityMatcher
12. @SpringBootApplication(scanBasePackages = "org.eclipse.hawkbit") (otherwise for instance flyway doesn't work - suffix is default ".sql", not H2.sql and don't differentiate dbs? strange is there a change?)
13. @NonEmpty for Long leads to validation exception - replaced with @NotNull
14. RSQLUtilityTest.correctRsqlBuildsPredicate - fixed - mock query builder add method
15. https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-3.0-Migration-Guide#spring-mvc-and-webflux-url-matching-changes - aliases as targers/ return 404 - remove trailing slash
16. firewall tests (allowedHostNameWithNotAllowedHost) doesn't throw 'rejected exception' but return 400 instead (as probably is expected anyway)
Signed-off-by: Marinov Avgustin <Avgustin.Marinov@bosch.com
* Fix tenant listing to do not mix with multitenancy
Tenant metadata is not multitenancy aware while depend on distribution set type
which is. Thus querying all tenant metadata (in non tenant context) sometimes leads to
resolution of distribution set type which is tenant scoped and leads to problems.
So, now listing tenant lists just their ids - not fill entities.
Signed-off-by: Marinov Avgustin <Avgustin.Marinov@bosch.com>
---------
Signed-off-by: Marinov Avgustin <Avgustin.Marinov@bosch.com
Signed-off-by: Marinov Avgustin <Avgustin.Marinov@bosch.com>
* [#1548] Add support for dynamic rollouts
-- Current status --
Initial draft only !!!, to be improved
TODO:
* evaluate the target count - if update group/rollout total count fails dynamic updates could (?), actually, contain more targets
* is it needed to break handler on group creating?
* if dynamic group schedulers occur to be heavy - maybe a handler per tenant will ensure that one tenant won't break all
*Concept for dynamic groups*:
Rollouts are static and dynamic.
Static rollouts consist of static groups only while dynamic rollouts have a number of static groups (first groups) and then an unlimited number of dynamic groups.
Group targets assignments:
* static groups include ALL matching targets created at the time the rollout was created, nevertheless they have active actions with bigger weight or not. Actions for the rollout and included targeets however are created at the start time.
* dynamic groups however are filled in when started and consider the action weight. The targets included in a dynamic group are:
* matching (filter and distribution set compatible)
* not included in this or following rollout static groups (if already included in any of the following rollouts - it's intended to be overridden)
* not in active actions of any rollouts with equal or bigger weight
In general, when you create a rollout it contains all matching targets available at create time overriding any previous rollouts, actions, and so on. If the rollout is dynamic when its dynamic group becomes running it gets only matching targets that doesn't belong to static groups or have actions with great or equal weight
Signed-off-by: Marinov Avgustin <Avgustin.Marinov@bosch.com>
* [#1548] Add 1000 weight for actions, rollouts and auto assignments without weight
Signed-off-by: Marinov Avgustin <Avgustin.Marinov@bosch.com>
---------
Signed-off-by: Marinov Avgustin <Avgustin.Marinov@bosch.com>
