Story #8140

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

Added by dalley about 1 month ago. Updated about 1 month ago.

Start date:
Due date:
% Done:


Estimated time:
Platform Release:
Sprint Candidate:


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.


#1 Updated by about 1 month 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.


#2 Updated by dalley about 1 month 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.

#3 Updated by dalley about 1 month 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.

#4 Updated by dalley about 1 month ago

  • Status changed from NEW to ASSIGNED
  • Assignee set to dalley

#5 Updated by daviddavis about 1 month 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.

#6 Updated by dalley about 1 month 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.

#7 Updated by about 1 month ago

For katello, it looks like we just display what is present and don't expect certain keys explicitly

#8 Updated by dalley about 1 month ago

  • Status changed from ASSIGNED to CLOSED - WONTFIX

We can change the codes instead.

Please register to edit this issue

Also available in: Atom PDF