Project

Profile

Help

Refactor #3166

closed

Return a single resource from 202 API endpoints

Added by daviddavis about 7 years ago. Updated about 5 years 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

Actions #1

Updated by daviddavis about 7 years ago

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

Updated by daviddavis about 7 years ago

  • Description updated (diff)
Actions #3

Updated by bmbouter over 6 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.

Actions #4

Updated by amacdona@redhat.com over 6 years ago

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

Actions #5

Updated by daviddavis over 6 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.

Actions #6

Updated by bmbouter over 6 years ago

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

Actions #7

Updated by amacdona@redhat.com over 6 years ago

  • Groomed changed from No to Yes
  • Sprint Candidate changed from No to Yes
  • Sprint set to Sprint 35
Actions #8

Updated by daviddavis over 6 years ago

  • Status changed from NEW to ASSIGNED
  • Assignee set to daviddavis
Actions #9

Updated by daviddavis over 6 years ago

  • Status changed from ASSIGNED to POST

Added by daviddavis over 6 years ago

Revision 759c59b3 | View on GitHub

Return a single task in task responses

ref #3166 https://pulp.plan.io/issues/3166

Actions #10

Updated by daviddavis over 6 years ago

  • Status changed from POST to MODIFIED
  • % Done changed from 0 to 100
Actions #11

Updated by dkliban@redhat.com over 6 years ago

  • Sprint/Milestone set to 3.0.0
Actions #12

Updated by bmbouter over 5 years ago

  • Tags deleted (Pulp 3, Pulp 3 MVP)
Actions #13

Updated by bmbouter about 5 years ago

  • Status changed from MODIFIED to CLOSED - CURRENTRELEASE

Also available in: Atom PDF