Pulp

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.

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'.

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.