Nice choice of music :) On Mon, Mar 26, 2018 at 4:14 PM, Milan Kovacik <mkova...@redhat.com> wrote:
> On Mon, Mar 26, 2018 at 9:38 PM, Austin Macdonald <aus...@redhat.com> > wrote: > > > > > > On Mon, Mar 26, 2018 at 2:30 PM, Dennis Kliban <dkli...@redhat.com> > 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. > > btw A moving picture of how it's going to look like on the docs side > of things: https://youtu.be/E7zC6SElm4g ;) > > -- > milan > > _______________________________________________ > Pulp-dev mailing list > Pulp-dev@redhat.com > https://www.redhat.com/mailman/listinfo/pulp-dev >
_______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
