Project

Profile

Help

Refactor #3166

Return a single resource from 202 API endpoints

Added by daviddavis about 3 years ago. Updated about 1 year ago.

Status:
CLOSED - CURRENTRELEASE
Priority:
Normal
Assignee:
Category:
-
Sprint/Milestone:
Start date:
Due date:
% Done:

100%

Estimated time:
Platform Release:
Groomed:
Yes
Sprint Candidate:
Yes
Tags:
Sprint:
Sprint 35
Quarter:

Description

Currently, we return a list of tasks from endpoints in Pulp 3 (sync, publish, etc) but we should probably return a single item—a task/task group/whatever. This would make it easier for users to track the status of their request. See @mhrivnak's response here:

https://www.redhat.com/archives/pulp-dev/2017-November/msg00113.html

History

#1 Updated by daviddavis about 3 years ago

  • Subject changed from Return a single task or task group from API endpoints to Return a single resource from 202 API endpoints

#2 Updated by daviddavis about 3 years ago

  • Description updated (diff)

#3 Updated by bmbouter almost 3 years ago

I believe it's very likely that a single user call will generate multiple tasks. Think about work that is highly parallelized, the tasking system could make short work of that. Something like an applicability calculation that has many subproblems that can be done in parallel.

So if ^ is the need, how can we facilitate that? What is a good user experience in that area?

A bad user experience is if a user call returns a list of tasks that is really long. Monitoring would be almost as difficult as it could possibly be. You would literally have to query each task status or get them via a list, but in either approach you are checking like a lot of things.

A good user experience would be a way to have all of these tasks thought of as a group of some sort. We had "group tasks" in Pulp2. We could introduce a feature later that would address the motivating need in the first paragraph.

So all ^ is my reasoning to say that I think it would be good if Pulp only ever returned exactly 1 resource w/ the 202 response at GA launch and throughout the Pulp3 line.

#4 Updated by amacdona@redhat.com almost 3 years ago

+1 to return a single task. For situations with multiple tasks, a parent/group task makes sense.

#5 Updated by daviddavis almost 3 years ago

Thanks for the responses. In terms of the MVP, I am thinking since we only have single tasks so I think we should just make this change:

https://github.com/daviddavis/pulp/commit/aeb30622ae94738f06463f857fb331c4b11d1436

After the MVP, we can design a TaskGroup/ParentTask/etc which extends the Task class and could handle multiple tasks while still conforming to our current task response:

    {
        "_href": "http://localhost:8000/api/v3/tasks/88e44b2e-dc36-406f-a852-9ec4db47d58f/",
        "task_id": "88e44b2e-dc36-406f-a852-9ec4db47d58f"
    }

Or we could add new fields too if needed.

#6 Updated by bmbouter almost 3 years ago

+1 to your commit @daviddavis. I agree w/ that resolution.

#7 Updated by amacdona@redhat.com almost 3 years ago

  • Groomed changed from No to Yes
  • Sprint Candidate changed from No to Yes
  • Sprint set to Sprint 35

#8 Updated by daviddavis almost 3 years ago

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

#9 Updated by daviddavis almost 3 years ago

  • Status changed from ASSIGNED to POST

#10 Updated by daviddavis almost 3 years ago

  • Status changed from POST to MODIFIED
  • % Done changed from 0 to 100

#11 Updated by dkliban@redhat.com almost 3 years ago

  • Sprint/Milestone set to 3.0.0

#12 Updated by bmbouter over 1 year ago

  • Tags deleted (Pulp 3, Pulp 3 MVP)

#13 Updated by bmbouter about 1 year ago

  • Status changed from MODIFIED to CLOSED - CURRENTRELEASE

Please register to edit this issue

Also available in: Atom PDF