Story #6858
Updated by ipanova@redhat.com almost 4 years ago
GroupProgressReport will be a similar model as ProgressReport.
Each group progress report will have a message, code, done, total, and relation to the TaskGroup.
Plugin writers will create these objects to show progress of work that is expected to be completed by the tasks in the group.
Tasks that belong to the TaskGroup will update the progress report. All group progress reports needs to be created in advance so a Task can find the appropriate one, by code or message and update it.
Tasks will need to handle logic and figure out what exactly they need to update in the group progress report. For example a task in the migration plugin called `complex repo migration` will create a repo version, publication and distribution. That means, the task will update 3 group progress reports.
To avoid race conditions / cache invalidation issues, this pattern needs to be used so that operations are performed directly inside the database
> .update(done=F('done') + 1)
See: https://docs.djangoproject.com/en/3.0/ref/models/expressions/#f-expressions
Question: How do we figure out 'total' per each group report?
=====================
~~Alternative Solution (a modification of the earlier "progressreport aggregation" strategy): on the TaskGroup serializer add another field called `progress_report`. It will query the db and look for tasks that belong to the group and aggregate the results by task 'code'. For example group will have 4 syncing tasks, each task has code 'sync', in the aggregated report there will be total of 4 syncing repos and based on the each tasks status the done will be calculated. This implementation is limited to the name of the task, and it does not have that much flexibility in case tasks creates more resources. For example: a task in the migration plugin called `complex repo migration` will create a repo version, publication and distribution. However in the progress report field it will only record that '1 complex repo migration done'.~~
.