On Wed, Mar 28, 2018 at 10:21 AM, Austin Macdonald <amacd...@redhat.com> wrote:
> > > 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. > 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 <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 > >
_______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev