[Pulp-dev] Plugin relationship to tasks

[Austin Macdonald]

I spoke with daviddavis about this and I would like to narrow the scope a
bit. This discussion should be limited to endpoints that deploy tasks. The
possibility for collisions that David pointed out regarding
v3/content/<type>/ is real, but should be discussed separately because
Content objects should follow the pattern of the other plugin defined
objects. All of them are master/detail so the namespacing
v3/plugin/<type>/content/ would go deeply against the grain.


On Mar 15, 2018 10:53, "David Davis" <daviddavis at redhat.com> wrote:

I have an amendment to this proposal. Instead of namespacing just the
plugin task routes, I’d propose we namespace all plugin routes. Thus all
plugin routes would be namespaced under something like
“/api/v3/plugin/<plugin name>/“. For example, “/api/v3/content/file/” gets
moved to “/api/v3/plugin/file/content/” and so on.


For task routes, plugins could still route to a pulpcore viewset/action:

User route: POST /api/v3/plugin/file/repository_version/ add_content=[…]

Routes to: POST /api/v3/tasks plugin=file task=create_repository_version
add_content=[…]


AFAIK, we don't have a good mechanism for validating and re-routing
endpoints quite like this. Instead, a view or viewset would be created,
validation performed, and then a task is deployed. The task itself could be
a vanilla task from pulpcore though. Another issue is that a POST to
v3/plugin/file/repository_version/ implies that the resultant
repository_version is typed in some way. The created resource href would
still take the form v3/repositories/1234/versions/2/, so I think this is a
little misleading.

For the other endpoint:
 /api/v3/tasks plugin=file task=create_repository_version add_content=[…]

There is a still the problem is that POST requests should not contain
parameters that influence the allowable parameter set. For instance,
plugin=python might require an additional parameter that is not allowed for
the file plugin. In particular, this affects the auto-documented REST API.

However, the concept in general could work. I've adapted David's suggestion
and will present it side by side with the original idea. Note, this only
applies to "actions", which are sync, publish, add/remove, and
plugin-specific actions (including rich-dependency adding).

The difference between the two ideas is based in semantics. Both would
deploy the same task functions.

"Action Based"
POST v3/plugin/file/sync/
Note that "sync" is singular. This is a file-plugin action to sync using
the body parameters.

"Task Object Based"
POST v3/tasks/file/syncs/
Note that "syncs" is plural. This is a POST that creates a file-sync task
object,.

Discussion:
Another consideration is "Where will a Live API live?". A benefit of
David's proposal is that we would be providing plugins with a namespaced
area to do whatever they need, from live api to actions. We probably would
want to create this namespace for things like live apis even if we go in
the tasks/file/syncs/ direction. The only downside of this part of David's
proposal is that our endpoints will still be "action" verbs instead of
nouns, and I am ok with that.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20180315/d517e1e7/attachment.htm>