[Pulp-dev] Content Copy (between repos)

[Ina Panova]

one-shot approach sounds good to me.
+1


--------
Regards,

Ina Panova
Software Engineer| Pulp| Red Hat Inc.

"Do not go where the path may lead,
 go instead where there is no path and leave a trail."


On Thu, Apr 11, 2019 at 6:05 PM Daniel Alley <dalley at redhat.com> wrote:

> 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
>>>
>> _______________________________________________
> 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/20190415/0594fc7b/attachment.htm>