[Pulp-dev] Plugin relationship to tasks

[Daniel Alley]

Nice choice of music :)

On Mon, Mar 26, 2018 at 4:14 PM, Milan Kovacik <mkovacik at redhat.com> wrote:

> 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
>
> _______________________________________________
> Pulp-dev mailing list
> Pulp-dev at redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20180326/90f7f0cb/attachment.htm>