[Pulp-dev] Plugin relationship to tasks

[Austin Macdonald]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20180326/8b5d253d/attachment.htm>