[Pulp-dev] Plugin relationship to tasks

[Dennis Kliban]

On Wed, Mar 28, 2018 at 10:21 AM, Austin Macdonald <amacdona at redhat.com>
wrote:

>
>
> On Tue, Mar 27, 2018 at 6:11 PM, Brian Bouterse <bbouters at redhat.com>
> wrote:
>
>> In terms of removing POST /api/v3/repositories/<uuid>/versions/ from
>> core, I want to bring it back to the MVP language and REST which drove the
>> original design. The MVP has: "As an authenticated user, I can create a new
>> version by adding or removing content to the latest version." To
>> facilitate that in a generic way, we need a core endpoint to do that, i.e.
>> /api/v3/repositories/<uuid>/versions/. My concern is that removing it
>> would cause us to not fulfill our use cases without requiring more code
>> from some plugin writers. Also in terms of REST philosophy, POSTing to the
>> RespotoryVersion resource to create a new RepositoryVersion is the
>> traditional url design.
>>
>> For pulp_ansible, for example, the generic add/remove functionality at
>> core endpoint ^ would be meet all of the pulp_ansible user's needs because
>> of the way the pulp_ansible content is modelled. So removing this endpoint
>> means more work for pulp_ansible developers w.r.t creating repo versions
>> and providing tasks and endpoints. I don't see this extra responsibility on
>> plugin writers coming with a clear benefit.
>>
>>
> I'm sensitive to adding work for the plugin writers, but convenience needs
> to be discussed after correctness.
>
> I haven't seen a counterargument to the assertion that it is **incorrect**
> to control repo membership without allowing plugin validation.
>

We could add hooks for plugins to provide validation for each content type.
The Content model in pulpcore could define "add_to_repository_version" and
"remove_from_repository_version" methods that take repository version as a
parameter. The default behavior would be that exists now. The Content
models in the plugins could then override the methods and provide
validation needed for removing from and adding to a repository version. The
repository version REST api would then use these methods on the content
models to add and remove content.

Thoughts on this idea?



>
>> One idea I liked in this discussion is to have a documented convention
>> that encourages plugin writers to put their viewsets in a namespaced area.
>> They still need the ability to put them anywhere due to live API
>> goals/requirements so this would only be a convention for those tasks they
>> are offering directly to their users.
>>
>>
>>
>>
>>
>> On Tue, Mar 27, 2018 at 5:40 PM, David Davis <daviddavis at redhat.com>
>> wrote:
>>
>>> I like Austin’s task proposal in that the plugin writers can focus on
>>> serializers and tasks that can be easily integrated with core. That said, I
>>> agree on the counterpoints raise about the new resource endpoints and
>>> turning much of pulp into a task running system. So I am a bit mixed on
>>> which approach is better.
>>>
>>> I do think that we should remove POST /api/v3/repositories/<uuid>/versions/
>>> from core.
>>>
>>>
>>> David
>>>
>>> On Tue, Mar 27, 2018 at 3:49 PM, Austin Macdonald <amacdona at redhat.com>
>>> wrote:
>>>
>>>>
>>>>>    - /api/v3/repositories/<uuid>/versions/ endpoint does not perform
>>>>>    plugin specific validation which can lead to "broken" repository versions.
>>>>>    - Plugin authors don't have any convention to follow when creating
>>>>>    custom REST API endpoints for creating repository versions.
>>>>>    - As a result of ^, a user will have a hard time identifying
>>>>>    repository version creation APIs in different plugins.
>>>>>
>>>>>
>>>> I agree with these points.
>>>>
>>>>>
>>>>>    -
>>>>>
>>>>> My first inclination is to disable the ability to POST to
>>>>> /api/v3/repositories/<uuid>/versions/ and require users to use the
>>>>> plugin specific APIs for creating repository versions. However, I think
>>>>> that integrators of build systems that produce a variety of content types
>>>>> would have a lot more flexibility if they could use a single generic API
>>>>> endpoint to create a repository version independent of the content type.
>>>>>
>>>>> Let's continue this discussion by answering the following question:
>>>>>
>>>>>    - Should we disable the ability to POST to
>>>>>    /api/v3/repositories/<uuid>/versions/ and require users to always
>>>>>    use a plugin specific repository version creation API?
>>>>>
>>>>> Yes, I think we should disable POST to /api/v3/repositories/<uuid>/ve
>>>> rsions/
>>>>
>>>> Simplifying integration is important, but we should not sacrifice
>>>> correctness enforcement.
>>>>
>>>> _______________________________________________
>>>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20180328/d5dee003/attachment.htm>