one-shot approach sounds good to me. +1
-------- Regards, Ina Panova Software Engineer| Pulp| Red Hat Inc. "Do not go where the path may lead, go instead where there is no path and leave a trail." On Thu, Apr 11, 2019 at 6:05 PM Daniel Alley <dal...@redhat.com> wrote: > 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 >
_______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
