[Pulp-dev] Plugin relationship to tasks

[Austin Macdonald]

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.


> 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
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20180328/c3b7ec72/attachment.htm>