[Pulp-dev] Plugin relationship to tasks

Brian Bouterse bbouters at redhat.com
Tue Mar 27 22:11:43 UTC 2018


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.

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/20180327/940360f7/attachment.htm>


More information about the Pulp-dev mailing list