On Tue, Mar 27, 2018 at 6:11 PM, Brian Bouterse <bbout...@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 <davidda...@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 <amacd...@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@redhat.com >>> https://www.redhat.com/mailman/listinfo/pulp-dev >>> >>> >> >> _______________________________________________ >> Pulp-dev mailing list >> Pulp-dev@redhat.com >> https://www.redhat.com/mailman/listinfo/pulp-dev >> >> >
_______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
