[Pulp-dev] Content Copy (between repos)
Justin Sherrill
jsherril at redhat.com
Sat Apr 6 15:46:00 UTC 2019
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.
Justin
>
>
> _______________________________________________
> Pulp-dev mailing list
> Pulp-dev at redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20190406/cc5058d4/attachment.htm>
More information about the Pulp-dev
mailing list