[Pulp-dev] Content Copy (between repos)

[Austin Macdonald]

I think its possible you will have a url collision with variant 1. (We had
a similar problem trying to use /v3/publications/docker/)

variant 1:  POST /pulp/v3/api/content/rpm/packages/copy/
content_units=[...] source="..." destination="..."  [more params...]

Assuming that /pulp/v3/api/content/rpm/packages/<pk>/ is a valid url, it
can (unintended) capture "copy" and treat it as a PK. If you see this
error, I think it will manifest as " 405: POST is not allowed at this
endpoint", meaning the rpm-package-detail endpoint.

Variant 2 seems doable, and leaves the door open for some pulpcore code, if
it ends up being helpful.

On Thu, Apr 4, 2019 at 2:38 PM Daniel Alley <dalley at redhat.com> 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.
>
> _______________________________________________
> 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/20190404/b2ee36df/attachment.htm>