[Pulp-dev] Plugin relationship to tasks

Dennis Kliban dkliban at redhat.com
Mon Mar 26 20:43:07 UTC 2018

On Mon, Mar 26, 2018 at 3: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.

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.

>> 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/)

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:

If the above is true, that means the client has to be aware of
'/api/v3/tasks/file/syncs/<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.

>> 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.
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.

> 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.
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.

> Value #3: It removes "action" endpoints and replaces them with RESTful
> "creation of task" POSTs.
+1 to this. However, not enough value by itself.

> 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.
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.

> Value #6: Since the parameters of Task are saved, it will be possible to
> repeat tasks.

Same thing as for #5.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20180326/1436f813/attachment.htm>

More information about the Pulp-dev mailing list