[Pulp-dev] Plugin relationship to tasks

[Milan Kovacik]

On Mon, Mar 26, 2018 at 9:38 PM, Austin Macdonald <austin at redhat.com> wrote:
>
>
> On Mon, Mar 26, 2018 at 2:30 PM, Dennis Kliban <dkliban at 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