[Pulp-dev] Content Copy (between repos)

[Daniel Alley]

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 <bbouters at redhat.com> wrote:

>
>
> 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/20190411/6a2d2462/attachment.htm>