<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 27, 2017 at 9:52 AM, David Davis <span dir="ltr"><<a href="mailto:daviddavis@redhat.com" target="_blank">daviddavis@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">TL;DR<div><br></div><div><div><div class="m_-5115632353313422695m_-3270273825973729823gmail_signature"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>In Pulp 3 do we want to return a single task or list of tasks for endpoints like sync, publish, etc?</div></div></div></div></div></div></div></div></blockquote><div><br></div><div>Thanks for raising this. I noticed the same recently and wasn't crazy about it either.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div class="m_-5115632353313422695m_-3270273825973729823gmail_signature"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><br></div><div># Background</div><div><br></div><div><div style="font-size:12.800000190734863px">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.</div></div></div></div></div></div></div></div></div></blockquote><div><br></div><div>The only use case that comes to mind from Pulp 2 is applicability. Client hits an endpoint requesting lots of recalculation, the request handler batches up that work into several tasks, and the response could include references to those tasks. But as you point out below, Pulp 2 uses task groups to handle that use case.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div class="m_-5115632353313422695m_-3270273825973729823gmail_signature"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><br></div><div># Going Forward</div><div><br></div><div><span style="font-size:12.800000190734863px">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. </span></div></div></div></div></div></div></div></div></blockquote><div><br></div><div>You could have a single task that runs and then does whatever is necessary to spawn child tasks. The problem is that if you have a backlog of tasks, all the spawned tasks go to the back of the line, roughly doubling the amount of time spent waiting for an available worker.</div><div><br></div><div>You could have a single task that's in waiting state and already has child tasks, which were queued by the original http request handler. That would change the meaning of child tasks to go beyond just tasks created by the parent task, but it is not unreasonable.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div class="m_-5115632353313422695m_-3270273825973729823gmail_signature"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><span style="font-size:12.800000190734863px"><br></span></div><div><span style="font-size:12.800000190734863px">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.</span></div></div></div></div></div></div></div></div></blockquote><div><br></div><div>In Pulp 2 we have a "task group" concept. It's just a simple way to identify that a collection of normal tasks are members of a group, and you can track a single summary endpoint that shows how many of those tasks are in each state. It's simple and effective. At the REST level, a request handler generates a response with a reference to a group instead of a task. A client can then easily query for tasks in the group and track/present their individual states and progress as it sees fit.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div class="m_-5115632353313422695m_-3270273825973729823gmail_signature"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><br></div><div><span style="font-size:12.800000190734863px"><br></span></div><div><span style="font-size:12.800000190734863px">Always returning a single task could paint us into a corner or it could force us to provide a better user experience. Thoughts?</span></div><span class="HOEnZb"><font color="#888888"><div><br></div></font></span></div></div></div></div></div></div></div></blockquote><div><br></div><div>I would avoid overloading the task concept and instead build in the expectation that a 202 response can include a reference to a single task or to a task group, using normal REST constructs (media types or named hrefs for example) to identify what is in any given response. That would keep data structures focused on simple and clearly-differentiated problems while retaining API flexibility.</div></div><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><p style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px!important;padding:0px!important"><span style="margin:0px!important;padding:0px!important">Michael</span> <span style="margin:0px!important;padding:0px!important">Hrivnak</span></p><p style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px!important;padding:0px!important"></p><span style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px!important;padding:0px!important"><span style="margin:0px!important;padding:0px!important">Principal Software Engineer</span><span style="margin:0px!important;padding:0px!important">, <span style="margin:0px!important;padding:0px!important">RHCE</span></span> </span><span style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px"></span><br style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px!important;padding:0px!important"><p style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px!important;padding:0px!important">Red Hat</p></div></div>
</div></div>