<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 26, 2018 at 2:30 PM, Dennis Kliban <span dir="ltr"><<a href="mailto:dkliban@redhat.com" target="_blank">dkliban@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"><div><div>This proposal does not make the plugin writer's job any easier. This simply changes where the plugin writer is providing validation logic, in a serializer vs. in a view. <br></div></div></div></blockquote><div><br></div><div>It does make the plugin writer's job easier *because* it changes how the validation is provided, Plugin writers already have to understand how to create models/serializers (and it is very simple) for all the other objects. Seriallizer validation is much simpler than viewset validation because serializers are literally designed to do this. </div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><br></div>The other problem I see is that complexity for users is increased. Instead of having 1 resource for tracking task progress, there would be an infinite number of resources for tracking progress of tasks.  <br></div></div></blockquote><div><br></div><div>In the proposal, Tasks are Master/Detail. The user doesn't have to "track" it at all. They can still use v3/tasks/ to see all the tasks. Retrieving tasks will either be the same (v3/tasks/) or easier if they know the task they are looking for (v3/tasks/file/syncs/)</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div>I don't see the value added by the proposed change. <br></div></blockquote><div><br></div><div>Value #1: We have to do something to address the problem that adding/removing content to a repository without plugin input is incorrect. This proposal is one possibility, but it isn't valid to compare the value against doing nothing. Instead, if you don't like this option, we need to compare it to other proposals for how to involve plugins in tasks.</div><div><br></div><div>Value #2: Plugin writers no longer need to dispatch tasks. Plugin writers shouldn't need to understand the complexities of our tasking system. Pulpcore can handle task dispatching generally, plugin writers just set simple class attributes instead.</div><div><br></div><div>Value #3: It removes "action" endpoints and replaces them with RESTful "creation of task" POSTs.</div><div><br></div><div>Value #4: It creates a convention for endpoints. Right now we have </div></div></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div class="gmail_extra"><div class="gmail_quote"><div><br></div></div></div><div class="gmail_extra"><div class="gmail_quote"><div>v3/importers/file/1234/sync/</div></div></div><div class="gmail_extra"><div class="gmail_quote"><div>v3/publishers/python/1234/publish/</div></div></div><div class="gmail_extra"><div class="gmail_quote"><div><br></div></div></div><div class="gmail_extra"><div class="gmail_quote"><div>There is no logical place for add/remove to go because add/remove will not involve an importer. It will be irritating to the users if we don't encourage some consistency between plugins for the simplest Pulp functionality.</div></div></div></blockquote><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>Value #5: Task history becomes much more useful. Currently, the only data on a task that connects it to user-facing objects is "created_resource". This proposal will allow users to filter tasks by parameters. For example, they can filter sync tasks by "repository" or "importer". They can also use the detail endpoints (v3/tasks/file/ or v3/tasks/file/syncs/) to list tasks based on the plugin or action.</div><div><br></div><div>Value #6: Since the parameters of Task are saved, it will be possible to repeat tasks.</div></div></div></div>