Project

Profile

Help

Story #1206

As an API user, I can get summary status for a task group

Added by dkliban@redhat.com over 6 years ago. Updated over 2 years ago.

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

100%

Estimated time:
Platform Release:
2.8.0
Groomed:
No
Sprint Candidate:
Yes
Tags:
Pulp 2
Sprint:
Quarter:

Description

- Documentation on using the Group Task Status
- Add pulp/api/v2/task_groups/<group_id>/state_summary in urls.py
- Add a view to handle the new endpoint
- The view should check the database for the status of all tasks that have the specific group_id and return a status based on that information.
- The view should return JSON structure that looks like:

{
 "_href": "/pulp/api/v2/task_groups/0fe4fcab-a040-11e1-a71c-00508d977dff/state_summary",
 "finished": 4,
 "canceled": 0,
 "error": 1,
 "running": 3,
 "waiting": 0,
 "group_id": "0fe4fcab-a040-11e1-a71c-00508d977dff",
}

Related issues

Blocks RPM Support - Story #20: As a user, my applicability data is calculated in parallelCLOSED - CURRENTRELEASE

<a title="Actions" class="icon-only icon-actions js-contextmenu" href="#">Actions</a>

Associated revisions

History

#1 Updated by dkliban@redhat.com over 6 years ago

  • Blocked by Story #20: As a user, my applicability data is calculated in parallel added

#2 Updated by dkliban@redhat.com over 6 years ago

  • Blocked by deleted (Story #20: As a user, my applicability data is calculated in parallel)

#3 Updated by dkliban@redhat.com over 6 years ago

  • Blocks Story #20: As a user, my applicability data is calculated in parallel added

#4 Updated by mhrivnak over 6 years ago

I suggest keeping this model a simple as possible, removing these fields: state, task_type, progress_report, result, start_time, finish_time, exception, traceback, tags, and error. One of the advantages of this plan is that it keeps us out of the business of having to sum the state of n number of tasks into one representation of start time, finish time, and success/failure.

For summary status, I suggest a specific endpoint like this: /pulp/api/v2/task_groups/<group_id>/state_summary

... that includes a json object where keys are task states, and values are an integer number of tasks in that state.

This provides a client with a quick and easy way to track the progress of a group. If all goes well, it would wait for all to be in the completed state. For deeper inspection of failed tasks, it would GET something along the lines of /pulp/api/v2/tasks/?group_id=<group_id>&state=failed

I'm on the fence about calling the referenced tasks "child tasks". One of the primary ideas behind this approach is that a group is conceptually much different than a task. Rather than have a parent-child relationship between tasks, there is a group, and it contains tasks. Calling them children is unnecessary, I think, and perhaps even misleading.

Likewise, this may be a small issue, but I would call these "task_groups". The primary concept and noun is "group". It is simply a group of tasks.

#5 Updated by jsherril@redhat.com over 6 years ago

I suggest keeping this model a simple as possible, removing these fields: state, task_type, progress_report, result, start_time, finish_time, exception, traceback, tags, and error. One of the advantages of this plan is that it keeps us out of the business of having to sum the state of n number of tasks into one representation of start time, finish time, and success/failure.

For summary status, I suggest a specific endpoint like this: /pulp/api/v2/task_groups/<group_id>/state_summary

... that includes a json object where keys are task states, and values are an integer number of tasks in that state.

I had explicitly asked for 'state' and 'error'. A state_summary would make it easy, but being able to treat this task similarly to other tasks wrt to checking its status would be very helpful from a user point of view. This isn't a deal breaker but is very nice to have.

I'm on the fence about calling the referenced tasks "child tasks". One of the primary ideas behind this approach is that a group is conceptually much different than a task. Rather than have a parent-child relationship between tasks, there is a group, and it contains tasks. Calling them children is unnecessary, I think, and perhaps even misleading.

Likewise, this may be a small issue, but I would call these "task_groups". The primary concept and noun is "group". It is simply a group of tasks.

I'm fine with that, i had mainly asked for it to be not called 'spawned_tasks'.

#6 Updated by mhrivnak about 6 years ago

  • Sprint Candidate changed from No to Yes

#7 Updated by dkliban@redhat.com about 6 years ago

  • Description updated (diff)
  • Status changed from NEW to ASSIGNED
  • Assignee set to dkliban@redhat.com

#8 Updated by dkliban@redhat.com about 6 years ago

  • Status changed from ASSIGNED to NEW

The current plan is to create a custom QuerySet that will be used to retrieve TaskStatus documents using a group_id. The serializer associated with this QuerySet will summarize the status of all the tasks in manner similar to this:

{
'waiting': n,
'running': w,
'finished': z,
'error': y,
'canceled': x
}

#9 Updated by dkliban@redhat.com about 6 years ago

Here is the actual result from my implementation:


$ http -a admin:admin --verify=no GET https://localhost:/pulp/api/v2/task_groups/dc0dd137-dd90-4147-a537-c67851330a71/state_summary/
HTTP/1.1 200 OK
Connection: Keep-Alive
Content-Length: 127
Content-Type: application/json; charset=utf-8
Date: Mon, 02 Nov 2015 21:27:07 GMT
Keep-Alive: timeout=5, max=100
Server: Apache/2.4.16 (Fedora) OpenSSL/1.0.1k-fips mod_wsgi/4.4.8 Python/2.7.10

{
    "accepted": 0, 
    "canceled": 0, 
    "error": 0, 
    "finished": 1, 
    "running": 0, 
    "skipped": 0, 
    "suspended": 0, 
    "total": 1, 
    "waiting": 0
}

Note that I include all the states that we have along with a Total.

#10 Updated by dkliban@redhat.com about 6 years ago

  • Status changed from NEW to ASSIGNED

#11 Updated by dkliban@redhat.com about 6 years ago

  • Status changed from ASSIGNED to POST

#12 Updated by dkliban@redhat.com about 6 years ago

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

#13 Updated by dkliban@redhat.com almost 6 years ago

  • Status changed from MODIFIED to 5

#14 Updated by dkliban@redhat.com over 5 years ago

  • Status changed from 5 to CLOSED - CURRENTRELEASE

#15 Updated by bmbouter over 2 years ago

  • Tags Pulp 2 added

Please register to edit this issue

Also available in: Atom PDF