[Pulp-dev] Plugin relationship to tasks

[Brian Bouterse]

@asmacdo and I talked some and I wanted to share a few of my thoughts on
the plugin tasks problem statements.

I agree with a problem statement for pulp_docker for example that it would
be good for a plugin writer to add custom validation when creating a new
repo/version. I thought this idea was stated already, but I'll retell what
I had thought we would do to add plugin writer validation. We would make an
optional plugin writer hook that validates the entire repository when the
RepositoryVersion is being made complete. Also this would also allow a
plugin to "disable" the repoversion endpoint by always raising an exception
here.

The documentation convention is also a good outcome. It would recommend
that plugin writers put their views in a url namespaced by their plugin
name. I think we should do that.

The other main problem I've read about with what we currently have is that
the actions urls (sync, publish, export, custom views) would be all in
different areas of the API urls. This is identified as a problem, but I
think this is ok. It allows us to explain each of those parts of pulp
separately, which makes the understanding of the API still pretty easy.

I also believe another tertiary problem identified is that the 'sync',
'publish', and 'export' words are not restful and it would be good to
resolve that somehow. A restful API would be an easier API to use because
REST clients already know how to interact with a resource. Action endpoints
kind of break this.







On Mon, Apr 2, 2018 at 2:54 PM, Austin Macdonald <amacdona at redhat.com>
wrote:

> Thanks for the classifications.
>
> On Mon, Apr 2, 2018 at 2:37 PM, Dennis Kliban <dkliban at redhat.com> wrote:
>
> I think of these actions as 2 new types of resource in Pulp. Unlike
>> Remotes(Importers currently) and Content, these resources are singletons
>> that each plugin provides. Since users don't need to create new instances
>> of these resources it makes sense that they are represented by a View
>> instead of a ViewSet. Though we don't even need to explain that to plugin
>> writers. We just need to tell them that all operations that their plugin
>> provides for users need to be sublassed from ActionView.
>>
>> From the users point of view a GET on /api/v3/versionsactions/ to find a
>> versionaction href is the same as performing a GET on /api/v3/remotes/ to
>> find the href for a specific remote to sync from.
>>
>> Auto documentation would work perfectly.
>>
>>
> Its not that it would be "broken" or "wrong". I just think that users
> expect the documentation to include behavior and parameters-- ideally,
> there should be enough information to create a request. In this case
> however, the documentation just explains how to retrieve the necessary
> information. It works, but I don't think it is ideal that the user needs to
> make other GET requests to learn how to use an API endpoint.
>
> _______________________________________________
> 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/20180402/41e51f12/attachment.htm>