[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.


> _______________________________________________
> 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