The one-shot approach basically means that every plugin will need to implement this separately from boilerplate code. Therefore, I suppose the best course of action is to write a story to implement this for Pulp RPM, implement it there, and copy said boilerplate to the plugin template.
Any objections? On Mon, Apr 8, 2019 at 10:35 AM Brian Bouterse <bbout...@redhat.com> wrote: > > > On Sat, Apr 6, 2019 at 11:48 AM Justin Sherrill <jsher...@redhat.com> > wrote: > >> >> On 4/4/19 2:35 PM, Daniel Alley wrote: >> >> Content copy between repositories is critically important to Katello >> integration and is something that we have not really addressed yet. It >> also needs to be completed before the RPM plugin can begin work on >> depsolving. The story that results from this discussion should probably be >> put on one of the next 1-3 sprints and not wait any longer than that. >> >> Repositories are generic to all types of content, but copy operations >> between repositories will need type-specific options defined by the plugin >> for e.g. advanced copy w/ depsolving. Therefore we need to find a design >> for this functionality where it will make sense that makes sense from a >> usage perspective and an implementation perspective. >> >> To get this discussion started, here's some suggestions about how this >> could work from the user perspective (presented without much thought put >> into how it would be implemented). >> >> Create a "Copier" object, like a Remote, that stores it's own settings >> and has one or many endpoints (like "/sync/") that can be POSTed to and >> return a task and create a new repository version. >> >> POST /pulp/v3/api/copiers/rpm/$endpoint_name/ content_units=[...] [more >> params...] >> >> The copier would store settings such as "recursive" and the "source" and >> "destination" repositories. And let's say they can be overriden. >> >> Or, create new endpoints without any associated DB models, like one-shot >> upload does: >> >> variant 1: POST /pulp/v3/api/content/rpm/packages/copy/ >> content_units=[...] source="..." destination="..." [more params...] >> >> variant 2: POST /pulp/v3/api/copy/rpm/package/ content_units=[...] >> source="..." destination="..." [more params...] >> >> Since basic copy support (just copying the units, no depsolving, etc.) >> could in theory be implemented completely generically, it would be nice if >> we could provide that for free somehow. But I don't immediately see a way >> of doing so. >> >> I welcome any suggestions or input. >> >> A 'copier' object that has to be CRUD'd seems like unnecessary >> complication from a user perspective. I would go with the 'one shot >> approach' at first, i think most users are going to desire that over an >> actual object. >> > The one shot also makes more sense to me. It has fewer steps for the user > to take. I also don't see a generic version that core could offer to make > this easier for plugin writers than it is today. > >> Justin >> >> >> >> >> _______________________________________________ >> Pulp-dev mailing >> listPulp-dev@redhat.comhttps://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