<div dir="ltr">Nice choice of music :) </div><div class="gmail_extra"> <div class="gmail_quote">On Mon, Mar 26, 2018 at 4:14 PM, Milan Kovacik <<a href="mailto:mkovacik@redhat.com" target="_blank">mkovacik@redhat.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Mon, Mar 26, 2018 at 9:38 PM, Austin Macdonald <<a href="mailto:austin@redhat.com">austin@redhat.com</a>> wrote: > > > On Mon, Mar 26, 2018 at 2:30 PM, Dennis Kliban <<a href="mailto:dkliban@redhat.com">dkliban@redhat.com</a>> wrote: >> >> 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. > > > 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. > >> >> >> 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. > > > 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/) > >> >> I don't see the value added by the proposed change. > > > 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. > > 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. > > Value #3: It removes "action" endpoints and replaces them with RESTful > "creation of task" POSTs. > > Value #4: It creates a convention for endpoints. Right now we have > > > v3/importers/file/1234/sync/ > v3/publishers/python/1234/publish/ > > 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. > > > 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. > > Value #6: Since the parameters of Task are saved, it will be possible to > repeat tasks. </div></div>btw A moving picture of how it's going to look like on the docs side of things: <a href="https://youtu.be/E7zC6SElm4g" rel="noreferrer" target="_blank">https://youtu.be/E7zC6SElm4g</a> ;) -- <div class="HOEnZb"><div class="h5">milan _______________________________________________ Pulp-dev mailing list <a href="mailto:Pulp-dev@redhat.com">Pulp-dev@redhat.com</a> <a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/pulp-dev</a> </div></div></blockquote></div> </div>