Story #8140
closed
Story #7469: as a Pulp File user, I can have my repository auto published and distributed
As a user, I can distinguish which "action" progress report(s) come from within a task that performs multiple actions
0%
Description
If we mix multiple logical actions into the same "task", then progress reporting for that task will be quite messy. It'll contain all the progress reports for all of the actions without any way to distinguish them.
Suggestion: We add a new field to Progress Report named "stage" or "action", similar to the task name, and we sort the results by stage/action. "group" by stage/action would be nicer, but it would break the API. Maybe in the future.
Updated by dkliban@redhat.com almost 4 years ago
There is already a code field on a progress report[0]. Any new codes we add could be more descriptive. That should at least alleviate the problem.
[0] https://github.com/pulp/pulpcore/blob/master/pulpcore/app/models/progress.py#L95
Updated by dalley almost 4 years ago
- Status changed from NEW to CLOSED - NOTABUG
I think you're right, that's basically what we want. The name isn't very good, but I'll settle.
Updated by dalley almost 4 years ago
- Status changed from CLOSED - NOTABUG to NEW
Noooope. "code" is just the description of that particular line item, e.g. "downloading.metadata". We can't use that, we need a new one.
Updated by dalley almost 4 years ago
- Status changed from NEW to ASSIGNED
- Assignee set to dalley
Updated by daviddavis almost 4 years ago
One thing I thought of originally was that we could maybe rename the codes to include the action/stage (e.g. "downloading.metadata" would become "sync.downloading.metadata") but this is a backwards incompatible change and would likely break integrations that query task progress reports such as Katello.
Updated by dalley almost 4 years ago
It depends on how exactly they're doing it. If they look for specific strings, yes. If they just use the codes we give them, it'd be fine.
I don't know that we should assume that for all integrations that might exist though. You're right that the potential for breakage is there even if it would be fine for Katello.
Updated by jsherril@redhat.com almost 4 years ago
For katello, it looks like we just display what is present and don't expect certain keys explicitly
Updated by dalley almost 4 years ago
- Status changed from ASSIGNED to CLOSED - WONTFIX
We can change the codes instead.
.