Maintenance: Planio will be observing a scheduled maintenance window this Tuesday, November 5, 2024 from 03:00 UTC until 06:30 UTC to perform urgent network maintenance in our primary data center. Your Planio account will be unavailable during this maintenance window.
Story #1206
closedAs an API user, I can get summary status for a task group
100%
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
Updated by dkliban@redhat.com about 9 years ago
- Blocked by Story #20: As a user, my applicability data is calculated in parallel added
Updated by dkliban@redhat.com about 9 years ago
- Blocked by deleted (Story #20: As a user, my applicability data is calculated in parallel)
Updated by dkliban@redhat.com about 9 years ago
- Blocks Story #20: As a user, my applicability data is calculated in parallel added
Updated by mhrivnak about 9 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.
Updated by jsherril@redhat.com about 9 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'.
Updated by dkliban@redhat.com about 9 years ago
- Description updated (diff)
- Status changed from NEW to ASSIGNED
- Assignee set to dkliban@redhat.com
Updated by dkliban@redhat.com about 9 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
}
Updated by dkliban@redhat.com about 9 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.
Updated by dkliban@redhat.com almost 9 years ago
- Status changed from NEW to ASSIGNED
Updated by dkliban@redhat.com almost 9 years ago
- Status changed from ASSIGNED to POST
Added by dkliban@redhat.com almost 9 years ago
Added by dkliban@redhat.com almost 9 years ago
Revision 3530a858 | View on GitHub
Adds task groups status API endpoint
Updated by dkliban@redhat.com almost 9 years ago
- Status changed from POST to MODIFIED
- % Done changed from 0 to 100
Applied in changeset pulp|3530a858e37bcb2d690695df2d814a7ff226c965.
Updated by dkliban@redhat.com over 8 years ago
- Status changed from MODIFIED to 5
Updated by dkliban@redhat.com over 8 years ago
- Status changed from 5 to CLOSED - CURRENTRELEASE
Adds task groups status API endpoint
https://pulp.plan.io/issues/1206 closes #1206