[Pulp-dev] Content Copy (between repos)

[Brian Bouterse]

On Sat, Apr 6, 2019 at 11:48 AM Justin Sherrill <jsherril at 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 at redhat.comhttps://www.redhat.com/mailman/listinfo/pulp-dev
>
> _______________________________________________
> 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/20190408/0eeed451/attachment.htm>