[Pulp-dev] Plugin relationship to tasks

[David Davis]

I’ve had a chance to think about this some more this week and reread all
the emails. I think that the solution of just adding a hook is best. Each
solution seems to be imperfect and I think we still want users to interact
with objects (remotes, repositories, etc). I’d say I’m +1 on adding a hook
and -0 on the other proposals.


David

On Mon, Apr 2, 2018 at 5:02 PM, Brian Bouterse <bbouters at redhat.com> wrote:

> @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
>>
>>
>
> _______________________________________________
> 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/20180403/7ac8a332/attachment.htm>