AutoAssignChecker behavior

[troyanov]

Right now, when setting up Auto Assignment through Target Filters, the AutoAssigner expects the new auto assigned DS not to be in the targets entire action history.

https://github.com/eclipse/hawkbit/blob/d982bb9a5ff13b1b46fad6dc5de3dcc728087fa0/hawkbit-repository/hawkbit-repository-jpa/src/main/java/org/eclipse/hawkbit/repository/jpa/autoassign/AutoAssignChecker.java#L38-L44

This behavior blocks the scenario, when we want to do auto assignment unlimited number of times when changing tags back and forth.

Example:

We have three tags AppA, AppB, AppC. I want to select/toggle them and to have DS with AppA, AppB or AppC automatically assigned to the target.

But if we'll look how HawkBit is doing manual DS assignment via Management UI, it looks like it is using another logic for assignment check:

https://github.com/eclipse/hawkbit/blob/d982bb9a5ff13b1b46fad6dc5de3dcc728087fa0/hawkbit-repository/hawkbit-repository-jpa/src/main/java/org/eclipse/hawkbit/repository/jpa/OnlineDsAssignmentStrategy.java#L66-L72

Maybe instead of looking through all action history during auto-assign check, we could check if it is not currently assigned and not installed?

[laverman]

@kaizimmerm & @schabdo I would like to get your opinion on this, too. 🙂

[schabdo]

This behavior blocks the scenario, when we want to do auto assignment unlimited number of times

Exactly! Our intention was to prevent the user from accidentally creating infinite update loops. Think about two auto-assignment filter matching the same target: They will overwrite each other's DS in turns. As a result controller will be trapped and busy with installing infinite updates. That's why there is a difference between "manual" and "auto" assignment.

I was wondering about the use case driving the need for multiple assignments of the same DS to a target. May I ask you for more details? Don't get me wrong, I try to understand it.

[kaizimmerm]

I agree with @schabdo . Keep in mind that auto assignment was primarily intended to be used for initial device provisioning. Rollout management is the right tool for later deployments.

[troyanov]

We have some users that want to participate in beta testing and help us to test devices running latest firmware. We apply Beta tag on these devices, and later on with new beta ready we start a new Rollout.

Sometimes firmware can be buggy, and as a result some users are not ready for a long term beta run. They ask to revert them back to stable release, so we manually assign stable DS and remove Beta tag.

Later on, after the beta rollout is finished, a new user might ask for beta test participation. Since we don't want to start a new Rollout, we simply manually apply DS and Beta tag.

So I thought maybe instead of manually assigning DS (people make mistakes here), it would be cool just to toggle Beta tag and let the auto-assigner do the work.