<div dir="ltr"><div>I also want to look at how this will affect our user experience. With this change, I believe plugin tasks are put at the center of the user experience and the repositories, content, and versions are moved to the background. The user would think about what they can do foremost as a series of tasks. This is great in terms of organization, but I'm concerned its stepping away from what makes pulp special. I think Pulp is special because of its focus on content management (repos, version, uploads, sync, promotion, copy/delete, publish, export). Having the user think about Pulp as a task-running system takes Pulp a step closer to a software like RunDeck (<a href="https://www.rundeck.com/open-source">https://www.rundeck.com/open-source</a>).<br><br></div>What I like about the existing user experience (and API) is that it all centers around Pulp's value proposition (importers, syncs, associations, etc).<br><br>Does this spark any thoughts or ideas from others?<br><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 26, 2018 at 4:43 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 class="gmail_extra"><div class="gmail_quote"><span class="">On Mon, Mar 26, 2018 at 3:38 PM, Austin Macdonald <span dir="ltr"><<a href="mailto:austin@redhat.com" target="_blank">austin@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"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>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></span><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></div></div></blockquote><div><br></div></span><div>If we don't change anything, a plugin writer is responsible for creating a task that creates a Repository Version and a view which will perform validation and then dispatches a task. If we do make the proposed change, the plugin writer will still have to write the task code and then also a serializer that performs validation. The proposed change only removes the responsibility of dispatching a task which is 1 line of code. <br> </div><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><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></span><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></div></div></blockquote><div><br></div></span><div>My understanding of the master/detail pattern we are using for our other resources is that each task's URI will look something like this: /api/v3/tasks/file/syncs/<<wbr>uuid>/<br><br></div><div>If the above is true, that means the client has to be aware of '/api/v3/tasks/file/syncs/<<wbr>uuid>/' resource. The user would need to know how to interpret the response from each task type. There could be an infinite number of these tasks with many different arguments. So writing client code handling all those responses could become a nightmare. Right now the user just needs to know how to interpret the response from '/api/v3/tasks/<uuid>' for all tasks. <br></div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><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></span><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></div></div></blockquote><div><br></div></span><div>We don't have a problem. I agree that a user needs to know a whole lot of information to correctly create a working repository version for a complex content type such as a Docker manifest. Without all this information on hand, the user could easily create a broken repository version. However, a rich client could solve that problem. If the plugin writer wants to support simpler clients, she can provide an additional URL for handling the validation and additional logic for creating a repository version. We should probably have a recommended convention for plugin authors to use when adding additional URLs. <br></div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></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></div></div></blockquote><div><br></div></span><div>Dispatching a task is 1 line of code. Plugin writers should be aware of resource locking and how it works. They get to decide what resources are appropriate to lock when performing asynchronous tasks. <br></div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div>Value #3: It removes "action" endpoints and replaces them with RESTful "creation of task" POSTs.</div><br></div></div></div></blockquote><div><br></div></span><div>+1 to this. However, not enough value by itself.<br></div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></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/publ<wbr>ish/</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></div></div></blockquote><div><br></div></span><div>I don't think tracking history is one of the use cases we decided to support in the MVP. We should have a separate discussion on how we could accomplish this.<br></div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div>Value #6: Since the parameters of Task are saved, it will be possible to repeat tasks.</div></div></div></div></blockquote><div><br></div></span><div>Same thing as for #5.  <br></div></div><br></div></div>
<br>______________________________<wbr>_________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/<wbr>mailman/listinfo/pulp-dev</a><br>
<br></blockquote></div><br></div>