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
