[Pulp-dev] Task responses in Pulp 3

David Davis daviddavis at redhat.com
Mon Nov 27 14:52:00 UTC 2017


TL;DR

In Pulp 3 do we want to return a single task or list of tasks for endpoints
like sync, publish, etc?

# Background

Currently all task responses are lists of tasks in Pulp 3. For example, if
you call the sync endpoint, you get a list of one task back that tracks the
progress of the sync. Allowing a list of tasks allows Pulp to return
multiple user facing tasks with a single operation. Currently, all
endpoints that produce tasks currently will produce exactly 1 task. So why
add a list now if it only contains 1 item? With Pulp's REST API being
semver governed from the 3.0 release, we couldn't ever return multiple
tasks in Pulp < 4.0 because changing a single item to a list would be
backwards incompatible in the REST API.

# Going Forward

Returning a list of tasks creates a somewhat suboptimal user experience
where users have to query multiple endpoints to know if their job is done.
Maybe we should do this differently. Perhaps anytime an operation needs
multiple tasks, we should have a single task tracking them because that is
a better user experience.

This is effectively the "group tasks" concept we had in Pulp2 that we have
left out of Pulp3 currently. The user would monitor a single task which
shows counts of 'done' and 'not done' or something like that. With counts
though, you wouldn't know which of the tasks are done and not done; maybe
in addition to, or as a replacement of, 'spawned_tasks', the viewset could
be split into 'finished_spawned_tasks' or 'unfinished_spawned_tasks'. I
don't like these names, but you get the idea.

Always returning a single task could paint us into a corner or it could
force us to provide a better user experience. Thoughts?

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20171127/9558a187/attachment.htm>


More information about the Pulp-dev mailing list