[Pulp-dev] Plugin relationship to tasks

[Milan Kovacik]

What still makes me feel most comfortable with the plug-in--centered
tasks proposal is that it doesn't try to conceal what actually happens
behind the scenes: a plug-in specific task code is fired all the time
a new repository version is created, that uses multiple (generic) core
Pulp objects to work on/with as mere URLs rather than verbose json
blobs passed around, and that no repository version gets created
without a plug-in involvement.


On Tue, Apr 3, 2018 at 6:01 PM, David Davis <daviddavis at redhat.com> wrote:
> 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.

I wonder how the hook triggers would look like: what part of the core
would be responsible to select proper plug-in based on what criteria?
What if we later on need more action endpoints for instance repository
version "fork/clone"? Should we add more hooks then?
What if more fine-grained control of particular plug-in is required
for particular action endpoint? Should the plug-in hook just `if
endpoint == sync... elif endpoint == publish ... else...` it's way
thru?
How about custom plug-in action endpoint configuration? Should that be
passed-thru the generic core action endpoint? How that would be
auto-documented?
What if e.g pulp_docker doesn't need particular action endpoint, is it
cool to raise a 400? Isn't cleaner for both the plug-in writer and the
user not to have to expose such an endpoint in first place?
What about the plug-in custom async action endpoints that happen to
have to create a repository version?

Why workaround a design that doesn't seem to fit?

Cheers,
milan

>
>
> 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
>>
>
>
> _______________________________________________
> Pulp-dev mailing list
> Pulp-dev at redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
>